10 Tech Commandments
I remember the first time I heard the the Notorious B.I.G’s 10 Crack Commandments way back in late 1996. I was barely 20 years old, but I remember it vividly:
I’ve been in this game for years, it made me a animal. There’s rules to this shit, I wrote me a manual. A step-by-step booklet for you to get your game on track, not your wig pushed back.
I’ve never had any ambitions to be a drug dealer or rapper, but these lyrics (and many more) have had a profound effect on how I think about things.
Last year, was the 18 year anniversary of the death of the Notorious B.I.G., so while reflecting on his life by listening to all his music, I thought of my own set of rules. Originally, I released this list as a series of Tweets.
How do you ever know that you are correct? It is easy to make assertions about your correctness, but unless you take the time to prove your correctness with facts, it is only an opinion. It doesn’t stop there. After you have the facts, you can share them with your team members, which saves them research time. Anytime you have a technical disagreement on a project, don’t attempt to be the boldest font, be the correct font.
As a software developer, I’ve only wanted three things:
- Accountability for my work
- Autonomy to do what I think is best
- Ability and expectation to be judged by the measurements of my actions
I’ve been writing software for money in some way or another for over 20 years now. Younger Bryan (aka Yung Bleezy) liked to show how smart he was by writing code in a fashion that made the amount of effort to read the code linear to amount of effort it took to write the code. I wouldn’t want younger Bryan on my team. (I’d still accept him, and try to show him the error of his ways through good examples.)
I’m sure it is cliché, but you should write software like you are talking to a five year old. Concepts should be clear and succinct. Code should have a high level of cohesion, but ultimately be only good enough. I still enjoy a good puzzler, but that’s on my own time. On a team, effort should be placed on raising the ability of the lowest common denominator.
We’ve been fooled into thinking that being a leader means that you are somehow in charge. This pattern is prevalent in our industry (and everywhere else apparently). At the point someone becomes a senior level developer, they then are promoted into management. I don’t believe you need to be in charge to be a leader.
You lead by setting a good example.
You lead with empathy.
You lead by gaining trust.
If you aren’t doing those things, you are simply in charge. This is something to think about when your team you are in charge of is in disarray.
We are lucky. I’m constantly intrigued by the continual pouting that goes on in our industry. Face the facts: you make a large sum of money to type on the keyboard all day. Your life may be hard with your deadlines and peer/management relations. It’s also difficult because not everyone wants to play by the same rules. These people may make your life a living hell.
The next time you want to complain about your life, think about the person who has work outside for a living all year around: the person who delivers your mail, or fixes your road, or who cares for the wires that bring us all this precious electricty. Before complaining on some social media platform how someone’s words about some arcane technology is going to ruin your life, think about how good you have it.
A (not Black) friend of mine asks me why I always talk about race. My answer is simple, “I don’t want you to forget I’m Black.” My constantly talking about it helps me cope with the lack of diversity and inclusion in our industry.
I also want don’t want to forget that I’m Black. Plenty people have sacrificed careers and lives for the ultimate goal of equality, and I owe it to each and every one of them to be the best that I can be. The best Black software developer I can be.
