My Personal Development Principles

Having worked in various environments with differing levels of success. I've come to a few conclusions that I've forged into my 'personal development principles'. They will read like commandments with the difference being that all things are negotiable here. This is in some ways my own take on the Joel Score Test. There's probably plenty of things to argue about and I welcome the feedback.

This is what I aspire to do

So without further delay, here are my guiding principles in no particular order:

1. Thou shall write to abstractions:

Write to a contract, it's not much extra code. It'll be a prerequisite to writing tests. 

Creating an interface is simple and easy. It just needs to be implemented by a concrete class.

Abstract classes are just half-implemented classes that need to be finished by a concrete class.

2. Thou shall write tests that matter:

I was a late adopter to tests. And now that I have I couldn't imagine deploying any mission-critical code without have test coverage. However choose what you test carefully to fully get an ROI on your time. Tests also ensure you play nicely with code you didn't write.

You can also ask other developers to write a test to 'prove' their work to expedite the review process.

3. Thou shall not write monolithic repositories:

100+ projects in a .NET solution? Not if I have any say over it. If you have many teams, you should have many code repositories and gated so that commits are only done by the team responsible or via pull requests (outsiders).

Use individual repos as mid-level components to assemble the final product. Each repo should be versioned and tagged in source control. 

4. Thou shall know how to effectively use source control:

One of the single best ways  to gain productivity is to use source control effectively. Committing, branching and managing code is almost an art form. Conversely, if a team member is struggling with source control, you need to teach them how to fish in order to avoid a future headache.'

Seriously, source control chops on a team can make\break the whole operation.

5. Thou shall use CI\CD:

"Sorry guys, I broke the build" isn't as bad as checking out code only to find out that it is broken. CI\CD helps avoid "works on my machine" syndrome. You'll never know if your code will truly work on somebody else's machine if something is not continually building the latest code.

"Hey Kevin, can we see that new featured demo'd?" is painless if you're continually delivering your code to an environment often. You'll also be able to have real QA folks test things without being a developer themselves.

 

You can also ask other developers to write a test to 'prove' their work to expedite the review process.

 

6. Thou shall balance work\life:

I have a family and even if I didn't, I need to step away. And so should you. Never plan to deploy on a weekend, a Friday or after lunch. Put in controls so you mitigate getting into "OMG WTF just happened?" during family time.

7. Thou shall have all code reviewed:

Me, you, the boss and anyone else that wants to push code into the repo should have it reviewed. Even the best developer.

8. Thou shall pair program often:

Wanna learn something new? Watch someone else code and go through the same issues you would have and be open to possibly learning a better way. Plus it creates team cohesion.

9. Thou shall leverage make\buy wisely:

I love to build things but I have to resist the urge to re-invent the wheel. If there is a pay product that'll do exactly what you want, use it. Otherwise google your ass off some more to make sure. Then build it.

10. Thou shall make code open-sourced when possible:

Want free help on your stuff? Open-source it. Does it contain a trade-secret? Factor it out; and post the rest. Afraid your code isn't good enough? Perhaps you should work on your coding skills :) If you wouldn't post it, you probably need to ponder the design.

It's good for karma.

Oh and don't break any company rules :P

 

Wanna learn something new? Watch someone else code and go through the same issues you would have and be open to possibly learning a better way. 

 

11. Thou shall separate concerns:

Favor many classes that do very little as opposed to one class to rule them all. Be careful that any class does not go above x (arbitrary number) lines of code. It is a code smell.

12. Thou shall favor composition over inheritance:

Inheritance is a cool OOP feature. But only use it if the relationship between the parent\child is meant to be super strong. Otherwise create components and wrap them into a class. For example, create parts for the car; then create a car object and plug in the components.

13. Thou shall understand we are all human, plan for mistakes:

I make mistakes, you make mistakes and we should just accept that we will have a margin of error. Put checks\balances in place. You'll be surprised how many mistakes get made when you start catching them automatically. 

14. Thou shall teach others and thou shall learn from others:

Fish for folks at first, then teach them how to fish. Assume others have lots of expertise in fields you are weak at. Know what you're good at, know where your limits are.

15. Thou shall use Poor Man's Dependency Injection as the rule, an IoC container as the exception:

IoC containers are cool, magical, hip and a sure way to complicate an ordinary system. Favor Poor Man's DI and use a container in special cases.

 

I don't expect someone to recite a bubble sort algorithm but I do expect someone to know what a factory does in software.

 

16. Thou shall know software patterns:

I don't expect someone to recite a bubble sort algorithm but I do expect someone to know what a factory does in software. Not sure what a singleton is does? Google it. Ask someone. If you work for someone you can't feel comfortable with admitting your flaws. Change jobs.

Or you can click here to read my take on each pattern I know.

17. Thou shall have a rollback plan:

Plan for failure. If not you're going to upset your work\life balance real quick.

18. Thou shall not micromanage:

Assign tasks, let devs attempt to solve an issue their way within guidelines. Is the new developer too new? Pair program with them for a while.

19. Thou shall use the cloud:

Still running servers in your basement? Still paying that staff? Still dealing with their arcane OS? What about server update outages?

I use the cloud and sort of sidestep all of that.

20. Thou shall embrace YAGNI:

"You aren't gonna need it" is something you should ask when building something. If you use it, it's worth the time to maintain it. If not, it just dies on the vine and becomes something to deal with in the future and you got no ROI.

Kill feature bloat on the whiteboard.

 

"You aren't gonna need it" is something you should ask when building something.

 

21. Thou shall treat a dependency like a marriage:

It's easy to fall in love with another code library. But keep in mind that once you make the leap of faith and "hook up" with it, you now will have to deal with all the issues that go with it. Upgrading, breaking changes, etc. Oh and don't forget the divorce when you decide you want to move on.

22. Thou shall automate:

Got a complicated task? Is it repetitive? Prone to human-error? You should know that there are these things called computers that can do complex tasks over and over in a very error-free way. You should try it.

Great things to automate:

  • Tests
  • Deployments
  • Health checks
  • Monitoring

23. Thou shall not over-promise and under-deliver:

Don't bite off more than you can chew (and don't sandbag either). Be realistic with yourself. Scope hammer everything so that you can be successful.

24. Thou shall not obsess over the perfect solution:

If it works but isn't perfect, we'll call that good. If there is a better option AND it's worth the ROI. Then we'll consider doing it. Otherwise it's probably gold-plating.

25. Thou shall take big tasks and decompose into little tasks:

A little task is easy. A group of little tasks can solve a big task. Little tasks can get assigned and completed during a sprint, big tasks create hopelessness.

 

Don't bite off more than you can chew (and don't sandbag either).

 

26. Thou shall decouple:

If you can decouple, do it. If you need to cross platforms, use something such as serialization. Need a dependency? Hand it to a component via the constructor. Avoid using the 'new' operator inside a method unless it is a factory.

27. Thou shall track and payoff tech debt:

Software never will be done unless it is abandoned.

Treat it like a puppy. Understand it's needs.

Understand it needs room to grow.

Understand that it needs to go on a regimented diet.

Give it an exam, triage the issues; make continual changes.

Don't let the puppy die from loneliness.

Make sure to log all of the warts, issues and troubles into a bug tracker.

28. (Last but not least) Thou shall enjoy what you do:

Enjoy what you do. Enjoy what you do. Enjoy what you do.

Or make a change.