…summed up masterfully by Brent Ozar in just 45 minutes. All the ways you’re doing error handling wrong and don’t even know it, why that table valued function is going to bring the pain, and so much more. This should be required viewing for anybody who writes T-SQL.
Early in my career, I read everything I could find trying to become a better programmer. Over time I realized the most helpful material didn’t deal with a specific language or trendy workflow, but instead dealt with the psychology and philosophy of software development. Eventually I collected the ones that made the biggest impact on me and offered them to new team members as recommended reading. They reflect my problem solving and management philosophy pretty well.
The Old Testament – Joel Spolsky
- Don’t Let Architecture Astronauts Scare You
- Can Your Programming Language Do This?
- Fire and Motion
- Hard-assed Bug Fixin’
- Human Task Switches Considered Harmful
- Rub a dub dub
- Set Your Priorities
- The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
- The Duct Tape Programmer
- Things You Should Never Do, Part I
- The Law of Leaky Abstractions
The New Testament – Jeff Atwood
- It Came From Planet Architecture
- Sucking Less Every Year
- The First Rule of Programming: It’s Always Your Fault
- We Make Shitty Software.. With Bugs!
- Why I’m The Best Programmer In The World*
Apocrypha – Ted Dziuba
Noticed this gem trying out the Retool quickstart demo. Retool looks like a web version of MS Access, which I think is long overdue because not everyone wants or needs mocks and models and interfaces and tests and controllers and an api and dependency injection and my eyes glazeth over just to add a record to a fucking table that no outside user is ever going to see. Rock on Retool.
…is the chain of blocked tasks in the backlog. Ever leave a sprint kickoff feeling really confident about the planning that was done, only to find your team stuck a few hours or days later? No matter how well prioritized the backlog is, “priorities don’t mean anything if you can’t make progress” as rachelbythebay explains, and gives some advice on how to untangle the chains.
In a programming language like C# or Java, you tell the computer what to do, in order… SQL, on the other hand, is a declarative language where you declare the shape of your result set… You’re declaring the output that you want, not the methods the database server uses to build it. Oh sure, you CAN use SQL to declare the shape of your query plan, but generally that leads to heartbreak and despair…”
Click through to read all the reasons why, and when you should and should not force things.
An entertaining conversation with a colleague gave me reason to revisit the source code for the Apollo 11 flight computer…the one that landed the first humans on the moon. The comments are all too relatable.
An ABC News article runs through the best Easter eggs and comments. The full source code is available on GitHub, natch. If there is a lesson to be learned for modern software developers, maybe it’s this: you may not think much of your “temporary” solution, but often the first thing that works is good enough. This was good enough to put 12 people on the moon and bring them home. What’s the most enduring thing your temporary fix accomplished?
Agile is the theory that the product owner knows what they want, and deserves to get it good and hard.
…and it actually works.
…you know the Jira schema better than the project your team is building. And that’s ok. Karl Hughes explains why, and why the transition from contributor to manager is so hard for developers in What you give up when moving into engineering management.
As a leader, you’re no longer expected to write the most code, solve the hardest technical problems, or fix the trickiest bugs. Instead, you’re responsible for ensuring that your team can do these things. It’s hard for great engineers to move into management because they like being deeply focused on challenging technical problems, not hopping in and out of a dozen meetings every day.
Your job is to develop the developers.
I like to joke that 90% of my job is just telling developers “No you can’t rewrite that.” Joel Spolsky explains why, and why why you’re not reading this in a Netscape browser, in his seminal article Things You Should Never Do, Part I
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don’t have shippable code. You might as well just close for business for the duration.
You are wasting an outlandish amount of money writing code that already exists.
Which is why this parody template of a press release had me in stitches – Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY
When $FAMOUS_COMPANY launched in 2010, it ran on a single server in $TECHBRO_FOUNDER’s garage…Our existing technology stack has served us well for all these years, but as we seek to grow further it’s clear that a complete rewrite of our application is something which will somehow prevent us from losing two billion dollars a year on customer acquisition.
…the $FAMOUS_COMPANY backend has historically been developed in $UNREMARKABLE_LANGUAGE and architected on top of $PRACTICAL_OPEN_SOURCE_FRAMEWORK. To suit our unique needs, we designed and open-sourced $AN_ENGINEER_TOOK_A_MYTHOLOGY_CLASS, a highly-available, just-in-time compiler for $UNREMARKABLE_LANGUAGE.
Read the whole thing, as they say.
Legacy == Proven. It’s as true today as it was when Netscape was on top and threw it all away.