I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said.
> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.
This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget.
There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.
Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run.
> Being aligned with teammates on what you're building is more important than building the right thing.
I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it.
> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.
I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours.
> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.
This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc.
> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.
Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.
To offer an opposite position I pretty much disagreed with --or at least would heavy qualify-- with most points. The rest I thought were trivial.
> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.
Perhaps, but this is a worthless distinction, especially if the author does not define correctness. If it is mathematically correctness he is after I think experience has shown a program does not to be correct to be very very useful, and except for extremely critical situations is not a consideration. The same way a road does not need to be perfect.
> Being aligned with teammates on what you're building is more important than building the right thing.
Hell no! Every leader would prefer to go in the right direction at 50% of maximum speed, that going 100% in the wrong direction.
> There are many fundamental discoveries in computer science that are yet to be found.
True, but trivial. The same thing can be said about every theoretical branch of science like math and logic, and even for many experimental branches.
> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.
Perhaps, but if you work the other 4-6 hours at 25% of your peak you still would do more than double during the day. Besides, the 2-hour figure, although reasonable strikes me as anecdotic at best. If anyone knows about a study I would love to read it.
> Most measures of success are almost entirely uncorrelated with merit.
Without a definition of merit, this is worthless. And for that matter, a definition of success is also needed.
> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.
Really? Thinking is a valuable skill?, who would have thought?
> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry.
Or perhaps reaching that "effective" threshold is beyond human capacity. I think this claim is pretty insulting to the software industry in general too.
> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.
Perhaps? It is not that straightforward. Doing a CRUD app with Ruby in a team full of assholes will have a "larger impact" than doing in on assembler with a bunch of goodie-goodies.
> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.
Perhaps? Without further qualifying it is worthless.
> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.
This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget.
There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.
Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run.
> Being aligned with teammates on what you're building is more important than building the right thing.
I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it.
> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.
I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours.
> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.
This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc.
> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.
Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.