http://i.imgur.com/wt3qfwD.jpg

Developer’s Path To Greatness

Aleksei Pushkin
Aug 24, 2017 · 10 min read

I am starting a blog because Troy Hunt’s said so. I mean not like to me personally, but to the whole audience of his brilliant NDC Sydney talk which I’ve attended very recently. Also, because we cannot find a senior developer for my team for like a billion years already, and I am not ok with this!

Here’s the deal – there are very few people living in beautiful New Zealand. Among those there is a certain percent of developers. As with any other professionals, some developers are good, some are average and some are… Let’s say less than enthusiastic about what they are doing. As a person properly obsessed with IT I’ve always thought that this last category should be the absolute minority. I mean – come on, we have access to world’s most advanced tools that allow us to do so much. One must be totally nuts to not to do his or her best to touch as much of this sacred knowledge as possible and not to commit to the process of continuous improvement in this area! Or so I thought before I became a team leader for the very first time and tried to find a decent developer for my team. What I’ve realised then – most of the people are stuck in their professional development. And I’ve noticed – or so I think – two main reasons for this. From what I’ve found out based on millions of billions of hours spent in a meeting room with another junior or lower intermediate developer with 15 years of experience – all these nice people can be divided in two major groups. First group – people who genuinely enjoy doing IT-related activities – I mean development, testing, DevOps tasks etc. – but struggle to find a way to improve and to keep up with whatever’s going on in the industry.

Second group – people who don’t give a shit. They may tell you how much they like writing code and do architecture, but in reality it appeals to them just a little bit more than, say moving numbers in excel spreadsheet, cleaning floors or washing dishes. May be even less – I dunno. Write some code, tolerate your colleagues, collect your wage, repeat. These are not people I want my team of rockstars to work with, and to be honest – there are not very many of them. Therefore I am going to ignore them in this blog post completely and concentrate on the first group – people who could, and should improve, because New Zealand desperately needs good developers.

First, let me quickly tell you about our hiring process

When we receive a new candidate’s CV we ask them to complete an online coding test, to see if they can implement a very basic application. This is where the first problem rises – so far only 15% of applicants have provided us with the code of acceptable (for a senior developer) quality. Then we invite candidates to a technical interview, where half of them really struggle with simple LINQ queries, inner joins, and understanding of what a design pattern is. So far 7.5% of candidates made it to the meet-and-greet interview with a team, after which team members decided whether or not they would feel comfortable to work with this person. Sounds simple, yeah?

So, why does a person with ten years of experience assessing his or her C# skills as 10/10 cannot write a primitive LINQ statement without Re-sharper? Why someone, who talks about architecture with such passion, cannot name any design patterns and doesn’t know what the main purpose of DI is, apart from unit testing. I don’t know. But I will guess.

The Boss Baby by Dreamworks Animation.

Guess number one – stable but boring small time company. Closed environment, same job with the same people in a tiny company for the last seven years. You just don’t know what you don’t know and there is nobody around to tell you.

Guess number two – arrogance. Same story – you’ve spent last billion years with the same company which has grown from two developers and CEO into something more interesting. There are people who can tell you that you may be not as great as you think you are, and may be this is the time to finally read about this framework dominating the market. But youngsters know nothing and webforms are life.

Guess number three – laziness. Yeah, you’ve been sent to this fancy conference, but what’s the point if ya ain’t in office anymore? Loot some swag, have a lunch and bugger off straight after. You’ve got another three days of free meals ahead, yay! Why would you implement a new web service using anything but WCF and VB .Net anyways? Watching videos and reading blogs take time – this can be spent watching cat videos instead. Praise these fluffy bastards.

Guess number four – lack of ambitions and/or understanding of how the industry works. Sit tight, write the same code every day and expect that it will become better with each iteration. This kinda works for sports, why wouldn’t the same approach work in IT.

With all these problems identified – quite apparently my guesses cannot be anything but the ultimate truth – let’s talk about how we can fix this. Once again – these are going to be my very raw ideas and some of them will address more than one of the problems mentioned above. Or non of them. In no particular order.

So, how can you improve if you feel you are stuck at the same level for over a year or two?

Don’t trust yourself

Critical thinking is a thing. I do believe though, that in first instance critical thinking should be applied to your own ways, or in another words – “Consider your every idea as if it would be given by a XIX century illiterate radish farmer”. No offence to extremely old radish farmers. Every time when I start working on something new and I have more than one option how I can approach this, I start with a discussion. I quite literally let every one know what I am about to do in order to collect their opinions about my ideas. The goal of this exercise though is not to evaluate my own ideas – although sometimes this helps too – but to see if someone will shout the new one, of which I was not aware. After that I simply google – and google is one underrated development tool – keywords for whatever problem I am trying to solve. I take three or four top results just to check if there is a new framework, a design pattern or a tool I’ve never heard of that may help me. Then I google them as well. Then I choose whatever solution seems more appropriate and code shit out of it. This doesn’t mean I will make everything right from the first attempt, but this will lower the risk to do this wrong next time. This routine will also help me to update my inner cash of tech keywords for technologies and ideas that I may want to try in the future with something completely different, and keep up with the industry. Ish.

This does sound like a long and complicated process that may lead to confusion, and to be honest – it most likely will, but only for the first few times. However, later on, after your learning abilities will have been improved, this will turn into a good habit that pays off.

This doesn’t mean though that you shouldn’t trust your own judgements. This is just that first of all you must make absolutely sure that you’ve earned and deserved this trust.

Forget about your ego

And don’t you confuse ego for self confidence. Self confidence is a good thing, as far as it has reasonable limits. However ego – overblown of course for most of IT people – is your enemy.

In pretty much every culture and industry there is an equation mark between “years of experience” and “expertise”. Which is – as I’ve already mentioned above – not a case in a rapidly evolving industries such as IT or Engineering.

People that don’t have much of experience in general, may still have some bloody good ideas. Or they may spot a mistake that you’ve made. Opportunity to learn is the best thing that may happen to us in terms of getting new valuable knowledge. Don’t waste it, take every advice as an opportunity to become a much better version of yourself.

There may still be a situation though, when someone else is dead wrong and you are right. Well, that’s a great chance to teach them. But don’t you forget to make sure you teach them right things – otherwise mistakes made because of your suggestions will be on your conscience. Also remember, that teaching is a pretty darn good way to learn.

I am not a huge fan of quotations but I really like this one by George Bernard Shaw:

“If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.”

It kinda illustrates nicely the importance of communication and exchange of ideas. I guess. Whatever.

Naruto chapter 16. Translation by readnaruto.com

Make an effort

Doing things properly – like really properly – is hard. This requires dedication, focus and effort.

Studying new things is hard. This is only natural, that we hate all that complicated and boring theory, that we need to get through in order to get those amazing skills we want. Being able to do stuff is cool, and mostly helpful. However, knowing theory that backs up all that practical tricks that you’ve mastered will save your live once. Just imagine that you can make a nice bomb with a fancy WEB 4.0 timer on it. The problem is that you vaguely understand the concept of time – which was boring – so you’ve set it to 1ms. Nice bomb, great skills, true craftsmanship, shame you’re dead.

Ever seen these people in the conference talk audience, sitting in the darkest corner, browsing web or playing Angry Royal Crash Saga? Well, don’t be one of these guys. And don’t skip those useless, super technical sections in that Swift tutorial you’re planning to finish tonight. Studying properly is hard – but there is no way this won’t pay you back one day.

From “Maximum Effort” Deadpool Speedpaint (TheIYouMe @ YouTube)

Pragmatic != Lazy

Now, this is very tempting for me to say – “This is hard to do your job properly”. However my definition of “do your job properly” is likely to be different to what other people may think. So instead of – potentially – arguing about the definitions, let me put it this way – “to do your job and to improve your skills with every task accomplished is hard”.

Unlike studying, or playing around with your pet projects, your day job has some constraints. You are limited to a particular techlogical stack, you work in an uninspiring industry with very little room for innovations, and you must provide results within certain timeframes. That sucks. This also makes it easier to implement so called “pragmatic solutions”.

We often write some horrible code with a bunch of TODOs here and there, promising ourselves that one day we will fix it. We know that this is a lie because this day will never come. We just do the first thing that comes to our mind because we are being paid for solutions, not for GOOD solutions. We call this “pragmatic aproach”, but in reality it is not. We just increase the technical debt and we are still to pay this debt one day. The later we pay the higher interest – just as it is in the real world. We can even reach a point when the debt will become so enormous, it will leave us with the only option – complete rewrite. A colleague of mine called such state of a product development “Technical Bankrupcy”.

This doesn’t mean that you cannot be pragmatic – of course you can, and you must. However this is a matter of balance – good balance between following best practices and not overdoing things. For example you can use some extra time to master a new tool, library or framework that you’ve learned about and that can make your application more future-proof but still use the programming language you trust in the environment you know. Then the next time you may do something else and add another new tool to your toolset. And another. And another. And so on until you turn you brain into a Swiss Army-knife of problem solving.

Oh, and you already know how you can discover these new tools – google them, listen what others say and never give up on studying.

Never settle

And lastly remember – the road of self-improvement has no end. You will probably never become the best in what you are doing – unless all colleagues perish – but this doesn’t mean you shouldn’t try. Your knowledge and your abilities may be enough today but absolutely useless tomorrow? Who will want your MVC 4 skills when bio-electrical quantum serverless self-teaching microservices will dominate the world?

The modern IT industry is a crazy supersonic magnetic train, and if you miss it you will have very hard time chasing it. So please, check the time table regularly and keep your luggage packed.

Toy Story by Pixar.
)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade