Things I Believe About Software Engineering
I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said.<p>&gt; Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.<p>This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it&#x27;s all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it&#x27;s usually &quot;people will die&quot;. 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.<p>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&#x2F;plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.<p>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.<p>&gt; Being aligned with teammates on what you&#x27;re building is more important than building the right thing.<p>I&#x27;ve no idea why so many of you are up in arms about this. It isn&#x27;t about bowing to managers, or being a punching bag for others. It&#x27;s about making concessions as a group to define what you need to build, and the best way of doing it.<p>&gt; Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.<p>I&#x27;d stretch this to say that &quot;on average&quot;. Some days I&#x27;ll get 30 minutes of stuff done, some days I&#x27;ll fly through work for a solid 8 hours.<p>&gt; Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.<p>This is so true it hurts. I&#x27;m currently working on a project in an agile structure, and it&#x27;s going like many agile projects I&#x27;ve worked on in the past. Agile is used as a buzzword for &quot;fuck planning, just write user stories and be done with it&quot;, all while team mates bitch and moan about spending too long in &quot;planning&quot; 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&#x27;t work from a user perspective, etc.<p>&gt; How kind your teammates are has a larger impact on your effectiveness than the programming language you use.<p>Over the years, I&#x27;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&#x27;t share that trait.