See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction.
Taking responsibility, in my opinion, is a large part of what contributes towards being a professional - as opposed to simply trading time for money. Furthermore, it not only applies to Software Engineering but to any profession and everyday life.
Tip #4 (“Provide Options, Don’t Make Lame Excuses”) is especially applicable to Software Engineering. We solve problems, if the entire problem space was known already we wouldn’t have much of a job to do! As such, it’s almost certain that something will crop up that puts the proverbial spanner in the works - lack of knowledge (we need technology x but I don’t know it), missed corner cases, underestimated time or budget requirements. Whatever the problems are, providing options is without a doubt the only way to handle the situation.
Challenge 1
How do you react when someone—such as a bank teller, an auto mechanic, or a clerk—comes to you with a lame excuse? What do you think of them and their company as a result?
Frustration ensues! Receiving an obviously lame excuse feels like being dismissed - as if you’re not worthy of hearing the real reason for something. Having worked in retail as a teenager, I tend to be sympathetic towards the employee themselves as (in my experience) the lame excuse was often provided or encouraged by a manager. As such, my judgement falls more heavily on the company - indicating a lack of respect and care for their customers.
Challenge 2
When you find yourself saying, “I don’t know,” be sure to follow it up with “—but I’ll find out.” It’s a great way to admit what you don’t know, but then take responsibility like a pro
This is a pattern that I have tried to follow religiously for a long time. After getting over the phase of being an angsty, yet intelligent, teenager who thinks he knows everything “I don’t know, but I’ll find out” shows a confidence in ones own ability to learn and a willingness to put in the work to do it. It also provides a source of accountability as someone now expects you to go off and do it!
Recently at work, for example, we were investigating possible implementations of a new background task system involving communications with third party services via REST APIs. One of the failure modes was if one of the third party services were unavailable. Using the Circuit Breaker pattern was proposed to protect our system against the failing third party. When asked how one might implement a Circuit Breaker, my response was something along the lines of “I don’t know exactly, I have some ideas but I’ll find out”! Learning commenced and the Circuit Breaker was later implemented.