1. It is about the people!
Software needs to solve people’s problems. What really separates good from great developers is mostly their way of communicating with others and thinking in problems.
2. Make friends and be someone you would to have as a co-worker - Be positive!
You are probably spending more time with your co-workers than with your loved ones. Make sure to make the best out of it, make friends at work and you will see that work is much more bearable. Also it is a lot more fun!
Try to be the best version of yourself. Even if things are not working out so well. Most of the times, you being crumpy over something doesn’t make it better.
Currently things at work are not working so smooth - still I try to keep my cool and stay positive. I have already witnessed, how fast a pretty good mood at work can turn to a very bad one.
3. First make it work then make it pretty
Your first try doesn’t need to be perfect. More often it is more valuable to get something out in order to get some feedback.
Personally, I also do this without getting feedback from somebody else. When coding on my own, I write my code in a Test-Driven fashion and then refactor the hell out of the crappy implementation when done.
The result: You pretty fast have an idea whether your approach will be working.
When your approach is working, you already have the tests in place which will hinder you from destroying your effective (=doing the right thing) implementation. Another personal favorite of this approach is that the most important test cases are already in place before starting to polish.
The big benefit of this approach: Finishing a task is not hindered by writing a lot of tests. Personally, I also have the feeling that the tests are better since they are not bound to the implementation that much.
Word of clarification:
What I mean about tests here are “big tests”, mostly integration tests covering the basics. Unit tests are for me mostly written in the “refactoring phase” since changing a lot of interfaces often means to re-write a lot of unit tests. Integration Tests are much more stable in this department.)
4. Don’t let the need for perfection get in your way!
I think everyone is or was guilty of doing this: Spending way more time on something than you actually should have spent. When coming back after a while, you see a lot of things you could have done instead with this time.
5. Praise in Public, Criticize in Private!
Over the years, I often read about it and have witnessed it in practice. This rule really helps in multiple areas.
It doesn’t hurt since the critic is delivered privately. Also by praising publicly you set a good example on what is really appreciated.
Only adjustement I would make: You need situations where you can be really open about things within your team. If no boss or other report is around, your team culture has to allow to bring up such, even personal topics. No harm done, since you didn’t run to the boss.
If there is a problem (e.g. a missed deadline by your team) try to own it as a team.
6. Embrace the unknown - Stay curious!
There is no reason to be ashamed if you don’t know something (yet).
For me the greatest things at work are when you can really dig yourself into new topics or get deeper knowledge on things you already know. Doing the same thing over and over again is kind of boring.
7. When in doubt - don’t guess!
Not everything is as obvious as it seems. In my experience complains about inefficient code are more often not justified. In the past I had a few cases where I said that the code is really not as performant as another solution, just to learn that the compiler optimized the shortcoming away and the first solution was much easier to read. Over the years you get a lot of situations where your gut feeling is showing you the way - still this should be covered by experience and not by wild guessing.
8. Your time is not the most important one
I am sometimes also guilty of this myself: Periodic quick questions to your colleagues about something which would take you 5 minutes of your time to look it up. Answering to your really quick question might really wreck their productivity (also have been on the receiving end).
9. You don’t need to code in your spare time
If you want and have time - awesome. If not, probably nobody cares. Take a well deserved rest and start your next day with a fresh mind. This often helps more than doing something you might not be enjoying.
10. Have a life outside of work
This helps especially when things don’t go well at work. To be honest, I really like going to work for different reasons. Still, even if you have your dream job, it is important to have something else. What happens to you once it is gone?
Bye
I hope you enjoyed reading this article and could take away something with you. I would really love to hear about your opinion on rules to live by as a Developer.
Feel free to share them on Twitter or any other social media channel.
About the Author:
