Over the last 4 years I’ve been working I’ve picked up a few knowledge nuggets along the way. I thought now would be a great chance to deep dive on some of those so that they aren’t forgotten (by me).

It’s better to let people know that your project is not going to plan early, rather than overworking to get it over the line. I’ve seen this done countless times, by myself and others. Pretending a project is getting along fine, and secretly dying inside because there is so much work to do. You are much better off just being upfront about where a project is at, and letting them know that you understand where you think it will end up, what might be missing, and how you plan to get the rest done on a more manageable timeline. Tricking yourself into thinking that it’s all going to work out is just going to result in a low quality rushed project, which likely isn’t finished.

Know what you want to learn next. At any one time, you should know what it is you want it is you want to learn next. You don’t have to have a month long learning plan mapped out, but if someone was to give you time to study out of no where, then you should at least know what topics you’d like to start on. By constantly being mindful of what to learn next, you are constantly thinking forwards about where you may want to be growing.

You are going to be have a lot of “solved” problems. Without knowing what the problem might be, I can almost guarantee that you aren’t the only person who has struggled with it. Have a think about how you’d solve your problem, then jump on the internet and find out how this problem has been solved before. I’ve found the “Dear HBR” podcast a great resource on how to tackle common workplace problems, and Dear Sugar Radio as a great resource on how to tackle personal problems.

Find a mentor (or two (or three)). This one is much easier said that done. There is an awful lot of hard lessons to learn in the world of software. Having an experienced wall to bounce your problems off will allow you to solve them much faster than you otherwise could. If you work for a large company then you will probably be assigned a mentor or coach when you start, but even in a smaller company there should be plenty of people willing to help you out.

Build a life outside of software. When you are only good at one thing, then a lot of your self esteem begins to get tied to how well you are currently doing at it. Build a life where you a range of things which make you feel fulfilled. I’ve found group classes to be a great way of gaining a skill, and meeting new people.

You don’t need to spend all your free time developing software. When I was first starting out, I had the impression that a “true” developers are always writing software in their spare time. It was a depressing situation, because as much as I liked the occasional extracurricular programming that I was doing, it never felt like it was enough.

To be a good developer, you need to be a good person. I’ve seen a lot of teams suffer at the hands of someone who is technically proficient, but difficult to work with. It’s a chore to get them to change their opinions, they generally spend their energy making the team work in a way that suits themselves, rather than anyone else. They can be a proficient developer, but they slow everyone around them down.

Break down your work small to keep yourself engaged. The times in my career that I’ve found myself the least engaged have been when I have a massive task with no achievement checkpoints a long the way. After about a week on one task, I find it gets harder to stay on task, and I’m less engaged. I now try to avoid that situation for myself, and anyone else, by helping them break down stories small. Not only is value getting delivered earlier, but you are also clearing space in your head every time you complete a task.

I think that might be all I’ve got so far, but no doubt there is plenty more. I’ll likely expand on these theme over the next year, or write more detailed posts on some of the points here.