CommitStrip

- The ability and want to learn. I offer the following advice to every firefighter I teach: the day you think or believe you know everything, is the day you quit. (I'm a software dev. by trade with fifteen-odd years experience as an operational firefighter (and still am to this day)).

- Find a domain or two you have an interest (better yet, a passion) in, that isn't IT, and pair your IT skills to it. My day job is (more generally) emergency management, so I pair my geospatial analysis and programming skills to solve problems within the emergency management domain.

I don't think AI will completely take over, simply because of [1], though it will somewhat remove or reduce the need for 'generalists', where much of the workload is handled by AI, at the prompting of a software developer or engineer, much like how many farm hands were replaced by farming machines when they became a thing. That said, I think we're still half a century off AI truly replacing most software developers.

Humans will still be required to 'know what 'good' looks like' and ensure that whatever slop AI spits out actually fixes the problem. This is where domain-specific knowledge is incredibly valuable. See how you can apply your skills to make your interest or passion field better, using AI to your advantage, by exploiting your technical skills with domain-specific knowledge.

Most people think of firefighters as just that - putting out fires. That's only partly true though. We use a shiny, and fast, red…

TLDR: Computer program UX design has to settle for boring consistency and stop reinventing the UX wheel. Learn the best UX practices for your platform based on ACTUAL USER STUDIES and apply them.

UX design is like yeast in bread. Too much, the bread overflows the pan and burns everywhere. Not enough, the bread does nothing. Maybe the 90s UX designers didn't use enough and thus we had boring UIs. But today we have 99% yeast and 1% flour and oh it is ugly.

Hang the fads, no more gesture-first uninuitive magic PLEASE! Styling is not evil, contrary to the 'unstyled HTML only' crowd, but consistency first and foremost makes for good UX. Consistent (accessible, localizable) look & (undo-able, default cancelling data-destructive) behavior above all, then look at 'intuitiveness' etc.

My parents were on the cutting edge of technology. My dad had self-taught and setup auto-dialling dial-up WiFi accessed over PCMCIA cards that he and my mother used for desktop emails, eBay when it was brand new, 320x240 video messages, even some skype. There was nothing they couldn't do on the computer with a little bit of googling and poking around the Control Panel or registry.

Today, not so much. And little wonder. User-hostile OS, application design abounds.

All of the geniuses at these companies have cargo culted stupid stuff to a grotesque degree:

- flat button icons instead of 3d buttons with text (it saves localization costs!!!! at the cost of user confusion)

- hamburger menus instead of…

Well, customer data isn't stolen by actual hacking, in my experience it's humans.

So many companies, particularly younger ones, have zero interest in putting up barriers to access as the company grows because in the early days, everybody was trustworthy and "because bureaucracy bad". So all the customer emails, phones, addresses, birth dates (and, I'm guessing, in the US SSNs) routinely fly around in Excel files called something like "Order Metadata Report" and sent to 50 people in 5 departments each of whom has their own use for it (like counting customers). Judging by the Sony hack it's not just SMEs.

If you want to steal data from a company, just pay a student a few hundred bucks to take up an unpaid internship in marketing (particularly anything to do with emails or customer segmentation) and give him a USB key and teach him some VBA and basic SQL (making him useful for reporting). The interns always end up running the reports so have a lot of access, usually complete access - financial information is the only thing that's not shared around. More advanced companies have a shared database access built into the excel files with a single login for everybody which never changes (hello 300 angry users) so with a copy of this file, you have perpetual up to date information long after you're gone.

Then you try to stop them from doing this and the C-level folks will say something like "it's OK just this time" and "please stop slowing us down". Most of them will be gone to the…

Excel remains a tool.

It can be a really powerful one I agree. It's simple to use, a lot of people knows how to handle it. And it's probably one of the best tools to do some quick data analysis.

However, like every tool, it has its pros & cons. One of the main cons, IMHO, is that data tends to be mixed with processing a lot (but it also simplify usage, so...).

Overall spreadsheets have been really helpful. Retrospectively, there is a good reason why it triggered the personal computers boom in the 80ies. They are good adhoc tools that can help lot. And Excel is the dominant one.

However, there are tons of horror stories around Excel, worst case scenario, it has lead to wrong decisions affecting the world economy.

I've personally a few horror stories (fortunately, not affecting the world economy).

At my last job, we used an internal spreadsheet to evaluate costs and margins when answering contract bids. This spreadsheet was a monstrosity taking ages to compute and it was a nightmare to manage, sync, and share between all the participants.

I've also seen the traditional "on what did you work last week" spreadsheet, quite annoying to update, even more given that my workstation is under Linux...

I've also seen spreadsheets as specification documents, generating an xml file, which in turn, through some xslt, was used to generate C++/C++ headers files describing an interface between two sub-systems. The concept (automating spec to code translation) was really interesting.…

Those who made such "simulation" probably do have forgot or never learn a classic engineering practice (at least in Europe engineering) witch is named resilience.

We need resilient systems as more resilient as bigger is the impact of their eventual failure. In other terms stating we can made a big and complex enough smart grid to run "almost" an renewable means spend an incredible amount of resource to build a hyper-fragile unmaintainable monster that can malfunction at best most of the time.

Also the "little storage" they state is not little at all and most importantly it does NOT LAST LONGER. So far we have some long-lasting storage (pumped hydro) witch is very effective where you have enough mountains and basins, witch might be true for let's say Norway and to a little extent Swiss, but certainly not for let's say Germany. Compressed air storage seems to offer an option at a sufficient scale, but so far only some experimental plants exists and they have a significant amount of fragility and risks. Long story short: we haven't enough storage on scale to deploy almost only intermittent sources of power. BEVs can compensate an unstable grid for homes, but not for industry, hospitals, big infrastructures etc. Long story short those who claim such possibility follow this classic: https://www.commitstrip.com/wp-content/uploads/2020/05/Strip-Appli-stop-Covid-650-final.jpg sorry I do not have one in English but I think anyone can translate quick enough. A video equivalent is…

I recommend reading 'The Wealth of Nations'. As an economics textbook, it is fairly dated, but it makes the point that ten people with a specific specialization can do more than ten people all doing the same work at once. Therefore the value you can provide increases with specialization as you can be part of a team than can provide more.

My salary increased once I marketed myself as having a specific specialization, but the difficulty of finding a job increased too.

It is a basic application of supply vs demand. As, say, a PHP developer, you're competing with millions of other PHP developers around the world. There are plenty of jobs, but there are also plenty of people who are competing with you, driving your price downwards.

If you narrow it down to knowing a lot about a very specific framework or PHP system - for example, you know a lot about Laravel or Drupal, then you're competing with fewer people, and people are willing to pay more for an expert, but there are also fewer potential jobs.

There's also an associated risk. If you specialize in Laravel and Laravel goes out of style, you will have to remarket yourself as a PHP dev again... Some people specialized intensely in Microsoft Silverlight, and they ended up like this - http://www.commitstrip.com/en/2015/07/28/betting-on-the-right-horse/ (it's not a total loss, as some programming paradigms work across languages). With the risk comes increased reward.