It seems like the most unnatural thing for many programmers; this notion of 'live coding.' The very idea that we would choose to opt-in to real-time scrutiny can be enough to make some coders pine for the safety of a dark room at 2am, complete with headphones and Mountain Dew.
Stereotypes aside, as programming continues to be accepted as a mainstream discipline, it is becoming increasingly necessary to write code on the fly for a watching audience. Sure, the platform may be a conference, a live stream or a demo to a prospective client, but these are still pretty rare occurrences compared to the dreaded coding-test presented to candidates applying for programming positions every day.
Tech jobs (IT and Software Engineering in particular) are plagued with conflicting opinions on coding standards, design patterns and choice of language, with debate on these subjects having their place as useful discourse. However, most troubling seems to be the abundance of ego in the industry. Imposter syndrome lurks in the shadows of development teams around the world, and it's seeds are often planted in the first contact between rookie coder and employer in the coding test. More and more, from day one, we are expected to hold our own as we write what we hope is stable software with eyes on us at all times.
Coding Tests
This is probably the most common introduction to public programming a developer receives, as they prove their skills in the hopes of getting a job. Every hiring process differs from company to company, but is there a universal way to cope with the fallout from coding tests, successful or not? I would say the most important thing to avoid is a dent to your self-esteem.
There are a million different ways somebody could fail a coding test, and I find most aspects of them as contrived as traditional processes in terms of measuring a candidate's skill. I'm not however saying that they aren't valuable, just that they don't always reflect your true talents as a developer.
Try to remind yourself that not passing one company's test doesn't mean that you are a failure as a programmer, or that the all-too-common imposter syndrome is not really a syndrome at all, and must be proof that you're a fraud. Instead, take the fact that you even managed to code in front of somebody as a victory.
Programming is more personal than it seems. The way you write is a reflection of your style and thinking. To put that on show for everybody to see is no easy thing to do, especially when the prospect of employment is riding on it.
Take your time and get your priorities in order. Personally, I see the coding test as a trade off between the problem you have been asked to solve and the time in which you have to do it. If you don't have a lot of time, your priority is to get the job done. As long as you make an effort to explain where you think you could refactor the code, you're doing well. On the flip side, if you have more time, once you have solved the problem, show that you can actively improve code quality by using the extra time to refactor.
Pair Programming
Commonly adopted in large teams, pair programming allows developers to solve issues together, as well as providing much needed mentorship to junior developers. If you're junior, or even if you're suffering from a classic case of imposter syndrome, don't shy away from opportunities to program with another developer. A fresh pair of eyes not only helps you get your job done quicker, it opens up your perspective to new ideas and ways of solving problems. With the right partner you could find a valuable mentor and begin solidifying a foundation in a particular technology.
This obviously comes with a requirement; the need to code in front of somebody. Here we are again! The advice here is similar to that of the code test passage above, but by this point, it should be a little bit easier.
It's now time to start letting your guard down a little more.
When you're pair programming and you run into an area in which you have less knowledge, don't let your ego get the better of you. Be honest about what you don't know. It sets expectations for the person programming with you. What they choose to do with that is on them, but you can't say you weren't honest, and nine times out of ten, people are more respected for having the courage to say 'I don't know', especially in an industry where imposter syndrome is rife.
The fact is, by the time you have had a few more 'I don't know' moments in a pair-programming session with a more experienced developer, you will soon be at the stage where you're saying 'I've seen this before,' and 'I'll take care of that.' Pretty soon a new, fresh-faced, less experienced junior developer has arrived, and before you know it, the student has become the master. :)
Welcoming criticism (constructive and not so constructive..)
Sheesh. This is the part everyone is scared of when is comes to programming in front of people.
The reality is, whether you are programming in public or doing your darndest to code in solitude, you're going to be criticised.
The tech industry is sadly still full of ego. It's getting better, and I'm optimistic that positive change is accelerating, but that doesn't change the fact that the criticism you receive may not always be constructive.
Hang in there. Try to identify where somebody is genuinely trying to help you develop your skills and embrace it. Code reviews, pull requests, one-on-one meetings, these are all fantastic opportunities to get some easy to build-upon feedback on how you can be a better programmer. The worst thing you could possibly do, is take a valid piece of feedback and take it to heart. Experienced programmers will spot it a mile off, and the main thing it will do is serve to show that you lack confidence, you're insecure and as a result, less mature as a developer. This is never going to help your career progression. So, swallow your pride and let it level your skills up. You'll appreciate it in the long run believe me :)
As for not-so-constructive criticism, most of the time people who are outright rude are suffering from major insecurities themselves, not to mention a lack of maturity much like what we talked about above. If you're at work and you're getting abuse about the way you code (and I mean abuse) then discreetly speak to HR. There is never any justification for personal attacks on your code, especially if you are less experienced.
Failing that, if you've tried to get help and you're just not getting it, this could be a really good indication that it's time to change jobs. There are many companies out there looking to nurture developers and grow them in a fair, compassionate manner. You deserve better! :)
Face-time between devs and clients is increasing
It is becoming more and more the norm that developers have to interact with clients. As I've progressed in my career, I've found that I've had to balance my time between directly contributing to a product's codebase, building new features and fixing bugs, to developing more bespoke and client-focused software. This means more meetings and collaboration with external tech teams.
With this comes more possibility that you will be coding in front of somebody. For example, I've developed many custom RPA solutions for customers who wanted something very bespoke. On many occasions, this has meant working with a technical representative from a company I am working with. I've found myself in situations where the person on the other end of the Zoom call would say, 'this feature should do X but it doesn't quite do it. Is it fixable?', and I would end up writing the code changes 'live' as it were before testing with the client to make sure it is up to scope.
The first time I did this was nerve-wracking, but before I knew it, I was writing entire classes with somebody on a video call whom I'd only known for a week. The first time you do that and everything works first time, you feel pretty badass. From there on, it's a snowball effect.
Practice leads to confidence
There's no doubt that coding in front of people over and over again has made me more confident. If you're naturally quite insecure or suffer from the dreaded imposter syndrome, confidence is your gasoline. It's a scarce resource, but when you have it, and when you can use it, you're unstoppable. The annoying part is, as much as you don't want to do it, the very act of doing it repeatedly is how you become more confident.
When I was a fresh-faced junior, if my future-self had travelled through time and said to me: 'in the coming years, you're going to be writing a blog post about how valuable it has been coding in public' I'd have laughed in my face. (Right after I regained consciousness after fainting because I had just met my future self.)
Strings to your bow
You can never have too many strings. If you're a competent developer but also have the ability to hold a conversation and fix/develop solutions for customers in real-time, without worrying too much about how you look and instead seeing it as an opportunity for growth, you're a pretty valuable engineer.
So what are you waiting for? Put that side-project code you've been working on onto GitHub, make that YouTube video, write that blog post.
It's not easy, trust me, but in the long-run, it's totally worth it.
Top comments (0)