Launching the Rules
With 20 something years in software development, most of it as some mix of developer, architect, and manager, I’ve learned quite a bit on how to survive and thrive in software development. Or, at least I’ve learned a few things about what I think has helped me survive and thrive. I love sharing what I’ve learned works for almost anyone, what I’ve learned works for me, and general observations. After joking about “Jim’s Rules Regarding Everything” for quite some time - and with some encouragement from co-workers - I started writing down my little tidbits and now am making them available. While there are some things specific to software development, many of my rules are really about people and teams. Because of that, I hope many more people get benefit from these rules than just people in the software business. Click here for the master list of Jim’s Rules. Keep reading this post to learn more about the background of the rules and what to expect.
With this series, I’ll be sharing my thoughts behind many of these little rules with you. These rules are a mix of my own opinions as well as what I’ve learned from others and hopefully I’ll get to a few anecdotes along the way. My hope is to encourage you to form your OWN philosophy and rules on how to survive in the world of software development or whatever world you’re in. No one can give you a checklist. Your personality, background, and skills along with those of the people around you will determine the right approach more than iron clad rules.
The list, as of early 2021, consists of about 86 rules. I’m guessing that sharing these won’t take 86 posts. Quite a few form themes or otherwise make sense to talk about together, so expect several rules to be covered as a unity. I’ve got a few already in the can to be shared out over the next couple of weeks. My aim is to complete a post per week and keep a constant stream coming. You can read the article about Rule #1: Know Who Your Customer Is and What Your Product Is now.
The rules aren’t really in a particular order other than the order I happened to write them down in. I decided to leave them in that order as I don’t consider the list final anyway. If I find new rules, they’ll be added at the end, not mixed in the middle.
The Types of Rules, Roughly Speaking
I’m dividing the rules in to 5 rough categories solely for the purpose of helping me organize how I talk about them. Rules will overlap and rules will sometimes defy categorization so don’t put too much stock in these categories because I’m sure not putting a lot of thought into them! These categories are:
- Be People Focused
- Embrace Change
- Be Resilient
- Managing Your Work
- All Those Techie Things
1. Be People Focused
People are the reason we’re here (that’s rule 5 by the way) and when we lose sight of that, things inevitably go wrong or at least become a lot less fun. This will be the broadest category and most of the rules I fit into other categories could fit here too. Ultimately, understanding the team you have and how best to work with them will govern your success more often than not, so this category is crucial.
Some of my observations may seem new and radical (or bonkers (or idiotic)), but they will often be centered in either something I learned in some lesson from someone else long ago or a fusion of lessons. Rule 7: “Be polite, don’t be bashful” may ultimately be my own, but it’s very similar to other guidance you may hear like “Be firm but gentle”. I emphasize cooperation and similar themes (Rule 6: “Cooperation is a powerful force.”) because I have constantly seen how teams can move mountains when moving in the same direction. I may be an introvert, but I get over that because I see how teams make me better and many of our rules will echo that.
2. Embrace Change
There’s nothing more frustrating than completing a long project and finding out it’s no longer relevant to the user or organization. Been there, done that, will write about it. Embracing change is crucial to stay relevant and to deliver the highest value. It’s easier said than done in a lot of organizations, I hope to share a few things I’ve learned to either navigate slow-to-change organizations or to know when it’s time to get radical. You’ve probably heard of Agile Software development. That’s a good starting point for understanding software development project management and processes but we’ll look at how you embrace change even further both for your organization and yourself. Sometimes that change will be the kind of change you’re not usually thinking about. For example: Rule 21: “As team size grows, so does the need for formality”. There, we’ll be looking at how you evolve your processes as a team or organization goes from small to large.
3. Be Resilient
The rules that I lump under “Be Resilient” will fall into a few categories themselves. Sometimes, it will how to build resilient systems, other times how to build resilient teams, and other times, how to be resilient yourself. Resilience requires flexibility, so often goes hand in hand with Embracing Change. For example, Rule 37: “Automated test are my pillow” on the surface is about being resilient (knowing your system works), but also helps you embrace change by being able to detect failure faster.
Personal resilience often crops up in unexpected ways and has unexpected benefits. When we look at Rule 74, “Keeping standards high ultimately creates a better work environment”, we will see that not caving into the temptation to “go faster” makes for fewer surprises and means you more reliably get work done in the time you think would take over the long haul. This is as much about your personal standards as project standards and the like.
4. Manage Your Work
I could probably write books just on managing work. Many people have already. The rules I put in this category reflect the things I think are most influential on how I look at organizing and managing work. They are less about things like Scrum process, Scaled Agile, or the like. (BTW, a look through a certain large internet book seller revealed no books on WATERFALL software development!) “Minimizing work in progress” (Rule 64) will be a key part of being successful in this effort, but we’ll also discuss strategies like Rule 27: “Do the smart thing today so you can be lazy tomorrow”.
5. All Those Techie Things
I would be remiss if I didn’t include a few truly tech oriented rules, but those won’t be the focus of the series. Where I do veer into tech, it will still mostly be pretty generic or apply broadly. I break most of these out into a whole separate numbering scheme and they only represent about 15% of the rules overall. Still, we do have some techie rules in the main body of rules too because I feel they’re either too general to truly call technical such Conway’s law and it’s related rules in Rules 56-58, or could have broader application such as rule 51: “You are always locked into something. You can’t avoid it and it’s not necessarily bad. Be intentional on the choice.”
Conclusion
We’ll be casual and have some fun. Mostly, I hope we all learn something. By creating this series, I’ll probably learn even more along the way (see rule 75!).
And remember rule 71: “Never ask me my opinion unless you want it!”