Mistakes I made as an intermediate developer
Jack Finlay - September 18, 2019
Previously I made a post about mistakes I made as a junior developer. Since then I’ve made more mistakes, but also learned a lot. Now in an intermediate level developer role, there’s things that I wish I could have done sooner to get myself to this level. This piece, like the first, acts as a reflection on my career so far, but from the perspective of now having a lot more experience and moving past the junior title.
Responsibility
It took me months to come up with the courage to talk to someone about a promotion. I had been feeling rather bored with the work I was being assigned and finally decided to ask for more responsibility.
I should have done this sooner.
My boss agreed to my proposal, and offered to get me more involved in some of the planning and design sessions that I was interested in. The problem was that although they were recognising my skills and abilities, I didn’t engage enough at first. I found that I was often too quiet and not asking enough questions to clarify my understanding. If I had asked more questions, and been less passive, I would have gotten more out of the sessions.
Compensation
I made sure that with this new responsibility, that I was to be compensated for it. This actually involved me talking to someone I trusted on the team, and having them help bring up to my HR manager that I was wanting a raise.
The mistake I made here was that I was again too passive. I let them know that I was seeing all sorts of job listings for at least a certain amount, and that I was getting many calls about other opportunities for higher level roles. At this point, I felt like I was in a good position for a nice raise.
It turned out to be a decent raise for staying within a company, but the one I had expected was that of which you would normally get when you change roles. Which I thought seemed fair, given that I was effectively “going up a level”. I should have tempered my expectations and thought about it more rationally. From what I’ve seen, you will get more by switching roles than staying in one company.
Change
Despite the constant push from our team to make some major overhauls in the codebase, they never really eventuated. We pushed to use some new technologies that would be more performant and easier to develop on. We also pushed to change up our work methodology to an approach that would have suited the client we were supporting better. This largely fell on deaf-ears and we continued to work in the same manner, with no real, or lasting changes.
If you aren’t getting aren’t getting any traction with your ideas, sometimes it can be better to take them somewhere else.
In the end I took one of the opportunities I was being offered elsewhere, and changed companies. I instantly gained more responsibility, compensation, and moved into a team that uses the technologies I want to, a more appropriate methodology for work allocation, and is receptive to my ideas.
Assertiveness
I have found that as mentioned, I was previously too passive with my ideas for how things should be built. There are a large number of times where I have suggested a solution but we opted to go for another, resulting in having to rework the solution in the way I had suggested earlier when it doesn’t work out.
You need to be assertive when you suggest solutions to problems, if you feel like your way might work, ask other to explain why it won’t. You will be wrong sometimes, but you could also be right and save a bit of time. Slowing down to consider another approach may lead to a speed up and less rework.
Volunteering for difficult jobs
I often found myself not volunteering for the jobs that sounded difficult. This lead to the boredom of repetitive, unfulfilling, tasks that just destroy your morale. Given the opportunity to take on some tough tasks, I finally took the plunge, and it paid off greatly. I found it much more motivating to work on something that was challenging. Volunteering for the hard tasks has made it much more exciting and interesting to go into work for the day.
The flip-side of this is that you need to know your limits and when to ask for help. I have had trouble in the past from not asking for help early enough. Learning to recognise that I need help has helped me grow recently and to actually learn how things are expected to operate, rather than assuming from the code.
Conclusion
Despite a few issues, it was overall a good move for me to ask for a promotion. If you feel like you are ready to step up a level, just ask for it. Even if you don’t get anywhere title-wise, you’ll make it known that you are ready to take on more responsibility.
Most good things like a promotion don’t come passively. You have to go get it for yourself.
Try the difficult tasks. Don’t take the easy ones. You’ll never learn anything new from doing the same thing everyday. Ask for help if you need it, and try to learn the signs that you need to do so.
Feel free to email me, tweet at me, or scream into the ether, whatever suits. You do you.
Jack Finlay - Software Engineer in Melbourne, Australia. Exploring the writing process and developing my skills through the occasional article on life as a programmer. Follow me on Twitter for updates.