What’s the most important part of a developer’s job?
I’ll make it easy for you – being a better developer.
Maybe your boss would have a different answer – “ship the product faster,” “ship with no defects,” & etc.
The thing is, being a better developer will help you do the things your boss wants, but more importantly it’ll make your job easier, reduce stress in your day to day life and radically improve your job prospects.
Why is that? Because the better version of you ships more code with fewer defects, is familiar with more and newer technologies, and has a strong profile in the local and international development community.
Big talk, right? Let’s check out some of the things you can do to get started.
Sounds like fun, right? It is, but it can also be a little scary.
Because when I say make something with a new technology, I mean learn the new tech, build something delightful with it, and then show it to the world.
By showing it to the world, I mean at a minimum putting it on github/gitlab/bitbucket/etc and linking to it from your personal site or LinkedIn account.
That can be a little intimidating sometimes, but it’s definitely worth it.
Here’s why you’ll improve as a programmer:
So what are you waiting for? Pick a tech and dig in!
I’ve written in the past about how people produce better results working in a group.
If you’re not doing it already, I’d suggest at a minimum asking someone to do some pair programming with you.
This can be a little confronting at first, for both you and your buddy.
It exposes the little day-to-day mistakes we make, puts our problem-solving skills on show and forces us to own up to things we don’t know or don’t understand.
What I’ve just described is of course the flip-side of the benefits or pair programming:
But that’s just the start. If you pair with a more senior developer, you’ll:
If you’re the senior dev pairing with a junior:
This isn’t necessarily a recommendation for taking up pair programming across your organization forever. Just something you can try to see how it works. If it produces better results, stick with it J
This is common advice on becoming a better programmer, but I don’t think it’s delivered in the right context.
Certainly, I’ve tried following it before, but sitting down to read some random code – awesome as it may be – just doesn’t do it for me.
What has been incredibly useful for me is reading really really good code that’s in the domain I’m working in.
And I don’t just mean in the same language you’re working in – if you’re writing some networking code in C++, then checking out the latest implementation of B-Trees isn’t going to be that useful. But checking out networking code written by a programmer or organisation you respect could be a massive help.
This hasn’t helped me write clever code, but it has shown me
If you’re not sure where to start with some code, here’s how you can get started:
But if reading high-quality code is a good idea, surely contributing to it is an even better way to improve.
If you’ve managed to track down some open source code that’s in your domain, then there are some serious advantages to contributing to it:
All that adds up to being an awesome developer.
The day to day business of programming can get stale after a while.
If you’re in a position where you’re working on one or two systems, or you find yourself implementing the same kind of application over and over again.
As a junior dev, ask me how many times I implemented: fetch data file via FTP, parse and validate data file, load data file into database tables. Go on, ask. I dare ya 🙂
Anyway, now I’ve got that out of my system, the point is that we can get pretty rusty doing the same kind of work over and over again.
Enter the programming challenge.
These are usually a series of problems that’ll stretch your programming knowledge and skills. When I do them, I find 50% of my effort goes into researching concepts I haven’t dealt with since I did my degree. Or maybe I have to learn them from scratch.
A*, graph theory, permutations, AI – I don’t know about you, but this kind of thing doesn’t come up in my every day work.
Here are some good ones:
Programming competitions and challenges are going to stretch and improve you programming knowledge like nothing else.
Test Driven Development sounds so simple. Before you implement something – write a test for it!
It can actually be pretty mind-bending until you get used to it.
TDD is one of those practices that has rabid hordes both for and against it.
Opponents maintain that it produces reams of tests that become burdensome to maintain as code changes (as it invariably does).
TDD fans say that TDD produces more reliable code that’s well designed and easier to maintain.
Either way, it’s worth doing TDD for a while, because the major benefit of TDD is that once you’ve done it a while, it’ll change the way you write code.
The major revelation for me, was that it changed the way I think about interfaces between my modules – I started considering my code from the point of view of a user, rather than an implementer.
This means I was more likely to get the API right1 on the first or second attempt, rather than the nth2.
That’s just me. Other’s report that TDD conditions them to write small pieces of highly testable code that even without a slew of tests is highly maintainable.
If you feel like a TDD challenge, give Uncle Bob’s TDD Lesson a go.
We led with making something with a new technology. The next step up is to make a complete product, even a minimum viable product, publish it and promote it.
This has a few parts to it. Making something with a new technology might just involve implementing a fun feature – implementing a chat between phones, making a photo booth, stuff like that.
Implementing a product is different. This means considering graphic design, UX, user on-boarding, accessibility, internationalization and so on.
Then your product needs to be published – if it’s a mobile app you’ll need to navigate app store publication rules.
If you’re publishing your app to the web, then you’re suddenly your own devops staff! Slinging servers, setting up build and integration processes, the lot.
Finally, promotion. This might just be telling your friends and family. Or, working out how you can get the message about your awesome product out to the right people for as little outlay as possible (free is very doable).
Now, you might be thinking this doesn’t have much to do with improving at programming.
That’s true, but it has everything to do with being a being a better software professional.
Following through with a project like this will help you understand many of the needs and motivations of the wider business we operate in as developers, and will of course really grow and improve you as a developer.
Awesome bonus – your published project becomes a living, breathing example of your incredible programming skills for future employers.
If you live in any kind of metro area, there’s going to be a bunch of technology-related user-groups or meetups. At least once a year, there’s going to be a big tech conference in your closest major metro area.
These things are worth getting to, if you can.
This is because they provide you with two stellar opportunities:
Opportunity one is good, but opportunity two is great!
Even if you work with an awesome crew implementing best practice development, we can all benefit from being exposed to new ideas and new ways of doing things.
This doesn’t mean that you need to give up what you’re doing and copy someone else. It’s an opportunity to see what works for other people, and how they’ve dealt with the same kinds of problems you may be facing.
So the next time you’re faced with a problem, you’ll have an expanded range of potential solutions.
But one better than attending meetings and conferences is speaking at them.
That may sound alarming at first. But don’t think you have to get a TED-ready speech prepared.
Believe it or not, your unique experience is just as valuable to other programmers as theirs is to you.
Your value lies in the fact that it’s highly likely you’ve used a unique combination of technologies that other devs would love to hear about, or just have a good ‘war story’ about a tough problem, how you fixed it, and lessons learnt from that.
Once again, local meetups are a great place to start. If you find you enjoy that and get comfortable talking to groups, you can trade up to bigger occasions, like local conferences.
But even if you don’t feel like talking about programming, you can still share your knowledge by writing about it. This is a great way to meet people online, and you’ll still be building your reputation as an awesome developer.
Last, and certainly not least, is asking questions. In meeting at work, at meetups and conferences, everywhere you can. Often, this is the only way you can get information other people have.
Why? Because a lot of people consider their knowledge so fundamental they don’t bother explaining it.
Of course, it’s only obvious to them. So the only way you’ll sometimes get the information is to ask the question.
Better information leads to better decisions. Better decisions equal better code and fewer rewrites because of ‘requirement changes’ – a lack of information. That adds up to you being better at your programming job.
Sometimes it can be a little embarrassing asking questions, especially when everyone just ‘seems to know’ the answer already.
Try to push aside the fear of looking like a dufus and ask the question (assuming you’ve thought about it first).
Often, when you ask the ‘obvious’ question, you’ll see a lot of people raise their eyebrows and say ‘ohhhh’. They were afraid of asking the question.
So when is it a good time to ask?
If the topic under discussion is a large one (say, database optimization) you might want research that yourself.
But if someone’s talking and you get that “heyyy, that doesn’t make sense” feeling, that’s the perfect time to jump in and ask a clarifying question.
Don’t be afraid of being the first to ask.
Yeah, I put the TL;DR3 at the end of the article 🙂 Here’s a quick recap:
I understand that’s a lot! Please don’t feel like you need to jump in and take on all of that. Maybe pick one or two, and continue your journey to becoming a better dev.
Anything I missed? Let me know in the comments!