Our industry is famous for delivering projects late and over budget. Many projects are cancelled outright and many others never deliver anything near the value we promised our customers. And yet, there is a subset of software development organizations that consistently deliver excellent results. And they’ve known how to do it since the 1970s. In this post I’ll tell you their secret.
Category: Uncategorized (Page 2 of 6)
This no B.S. guide will tell you what you need to know to survive and thrive as a software developer at my workplace (or just about any workplace).
Congratulations on being hired. You have a lot to learn. It’s not the stuff you think. And you’ve got to learn it fast
We don’t care where you went to school, where you’ve worked, or about any of the things you’ve accomplished. That’s all in the past. You are starting from zero.
Stop me if this sounds like you. Somewhere along the way someone put you in charge of something at your job. Maybe you’re coaching a new hire, maybe you’re a technical lead on a small team, or maybe you’re running a whole project. Regardless of what you’re managing, you need to deal with people and that’s not going quite as well as you had hoped because managing programmers is hard. And it can be hard on your sanity.
(As an Amazon Associate I earn from qualifying purchases.)
Maybe you even picked up a book or two about management in the hopes that you’d find something–some trick or skill–to help you manage your people better. I can tell you from experience that most of those books are crap. But there are a couple of exceptions and in this post I want to give you a summary of one of them: The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever (paid link) by Michael Bungay Stanier.
I use a SAD light as soon as I wake up to go from groggy and useless to fully alert in a couple of minutes. Most mornings I’m sitting at my desk and working within 7 minutes of waking up. It’s one hell of a productivity hack.
I’m on a journey to become a better software developer by reducing the number of defects in my code. The Personal Software Process (PSP) is one of the few proven ways to achieve ultra-low defect rates. I did a deep dive on it over the last few months. And in this post I’m going to tell you everything you need to know about PSP.
Clean Architecture failed to meet my expectations on a number of fronts. Despite Mr. Martin’s obvious passion for the topic, Clean Architecture is poorly organized, lacks examples, and is silent on working with existing systems. The author missed a major opportunity to teach us when and how to apply these lessons to our own systems. Let me explain.
(As an Amazon Associate I earn from qualifying purchases.)
I bought a copy of PSP: A Self-Improvement Process for Software Engineers (paid link) by Humphrey Watts because I wanted to learn the Personal Software Process (PSP) on my own. I thought the book would have everything I needed to do that but the links to the programming exercises (aka assignment kit) in the book are dead.
No problem, I thought, I’ll just find them myself. Wrong. After a couple of hours of searching the internet, I still hasn’t found the PSP programming exercises. So, I finally asking for help on a forum and David Tuma was kind enough to point me in the right direction.
My survey of the computer science literature suggests there are only two economical ways to achieve extremely low defect rates (< 1 defect per KLOC). The first way is to follow the Personal Software Process (PSP), which was created by Watts S. Humphrey at CMU. The second way is to use languages and tools that make it difficult to introduce errors into your code in the first place and easier to detect errors if you do manage to get some into your code. In this post I’m going to briefly discuss these two options and how I plan to explore them to become a better software developer.
The more I learn about Tesla’s self driving car development, the more concerned I become about the ethics of working as a software developer on the Tesla autopilot software. Let me explain.
I’m sure you spend a lot of time thinking about how to write better software just like I do. And if you’ve dipped your toes into the waters of unit testing best practices, you will have undoubtedly asked this question at some point: how simple is too simple to test?