Learn how to be a wildly successful small business programmer
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).
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?
So, if you’re reading this it means you’re involved in a software project that’s a steaming mess and you want to explore your options. Don’t be embarrassed. This is a safe place; we’ve all googled “rewrite vs refactor” at some point.
The problem is that our profession is long on opinions and short on evidence for what to do with troubled projects. And the opinions we have are all over the map. So, it’s hard to know what you should believe.
In this post, I’m going simplify things for you and help you navigate the rewrite vs refactor debate.
© 2024 Small Business Programming
Theme by Anders Noren — Up ↑
