The Pragmatic Programmer is one of the most influential books that I have read as a software developer. It is right up there with Software Craftsmanship and Clean Code. Andy Hunt recently gave an interview that was peppered with several poignent quotes that struck a chord with me.
You need to understand how to work with other people, both with teammates and with those pesky users
This is the single piece of advice that I’d give to anyone looking to get into software development. A team that works well together can accomplish anything even if it is only staffed with “intermediate” developers. In contrast, I’ve seen teams stacked with “rock stars” that have failed to produce anything meaningful due to poor team dynamics and toxic attitudes.
Similarly, when it comes to our users. I had one particular user on a past project that would literally call every single day and open the conversation with a deep sigh before she began to describe the Problem Of The Day. I had to work really hard at not getting annoyed with her but the truth of the matter was that she was almost always right. She found more bugs in our system than all the other users combined and our software became much better simply because she was one of our users.
I hate languages that introduce accidental complexity, such as JavaScript
JavaScript is an abomination, in my opinion. As professional software developers we owe it to the world to identify and promote a viable alternative front-end language. In fact, I think it is up to us to stage a grass-roots strike and refuse to pollute the world with any more JavaScript.
I understand that well-written JavaScript can be beautiful but the majority of JavaScript that I have encountered has been a mess of callbacks and runtime errors. And don’t get me started on that astonishingly complicated build process. It’s just not a language I willingly choose to subject myself to.
Every project sucks in its own, unique and special way
There is no perfect project. No codebase is 100% beautiful. They all have warts. Our job as software developers is to find ways to minimize the bad stuff and foster the positives.
There were other challenges that were not successful, of course. Torpedoed by clueless or openly antagonistic stakeholders, internal political conflict
Almost every project I’ve been on has had at least one feature/request/decision that became its Achilles Heel. The stakeholders make a request that the technical team pushes back on, stating valid concerns, only to be overruled and forced to do something that they know will never work. These critical moments can precipitate the demise of a development team causing key members get frustrated and quit, and give rise to a festering animosity between the technologists and stakeholders.