As Forrest Gump once said, life is like a box of chocolates. Aside from never knowing what you’re gonna get, it’s also not divisible into black and white; there’s shades of brown, cream, and the occasional multicoloured filling. Life’s about balance, and finding the often-delicious middle ground.
(And sometimes you get nougat, but what can you do.)
Being the new developer on the team can be intimidating; sure, you may have worked with others in the classroom, but here you’re working with much more experienced professionals on projects with real-world consequences for getting it wrong. It’s nerve-wracking! And yes, this applies to pretty much any job, but the point still stands: what do you do to put your best foot forward and get the most out of it?
I’ve seen a few of these kinds of posts around the net over the past few months, and I thought I’d chime in with my own advice for new developers. Rather than being contentious and contradicting other people’s posts, I thought I’d just contradict myself in my own article. You’ll see what I mean.
Let’s get to the advice.
Q&A: asking for help
Don’t be afraid to ask questions
We were all new once. If you don’t understand something, ask! Your tech-leads and managers want you to get tasks completed in a timely manner and will usually be more than happy to assist you in this quest.
Also, as you start learning more and more, there are less things that you can ask for help on. Especially as you eventually become a subject matter expert. I don’t mean this to sound like a (humble)brag, but I’ve had times when it would make my life so much easier to be able to ask someone how to fix a problem with technology X. Unfortunately, I’ve been at the company the longest and I have worked on X more than any of my co-workers, so I have to figure it out myself. Take advantage of your ability to get help while you can, before it disappears as you improve your skills.
Don’t ask too many questions
Asking for help is great, but don’t do it too much! You don’t want to be the person who constantly has their hand held.
While your managers and tech-leads want you to succeed, they’ll be much more willing to help if they see you also trying to progress on your own. You can strike a balance by trying a few different avenues before asking for help. If you can go to them and say, I tried doing A, B and C and none of them worked, they’ll at least know you’ve made an effort and can see you’re growing.
Or, you could try time-boxing the task. If you’re really not sure on something, try for an hour to figure it out before asking for some advice.
Search for answers yourself
At the intersection of both of these tenets is the fact that if you’re running into a problem, you’re probably not the first person to do so. There are thousands of novice developers exploring new languages and platforms across the globe, and thousands of experienced devs who are willing to lend a hand. Google is an amazing resource. StackOverflow is an amazing resource. Blogs, guides, documentations and manuals, all of these and more can be found online.
Obviously talking to an experienced human being who’s right there can be faster, but how much faster? Taking an hour to solve a problem that your senior could solve in five minutes is obviously inefficient, but it’s also possible that it could be solvable with five minutes’ online searching. It’s always worth it to take those five minutes, look to see how much of a problem this has been for other people, and then decide… and if you choose to ask someone else, then that quick check can help to form a better explanation of the challenge that you’re facing.
Figuring out stuff on your own brings me to my next point.
Yes, No and Maybe: volunteering for challenges
Say yes to everything
Sometimes things are going to need to be done that are outside your realm of expertise. A number of times I’ve had little-to-no knowledge of a particular problem but I’ve put my hand up anyway. I’ve always been honest if I don’t know how to do something, but let the higher-ups know I’ll give it my best shot. They’re usually happy to get someone working on a fix right away. Just finding and on-boarding an expert to get started can take days of time.
There’s also no better way to learn than by doing. A lot of problems in programming are similar enough that you can apply your knowledge cross-domain. There’s even been times when I’ve been able to keep working on the product throughout the rest of its life and become the subject matter expert for it.
So say yes, but be honest – you never know how far it will take you.
Say no, a lot
Let’s be honest, some coding work is more critical than others. You’ve never used CSS before but your boss needs someone to centre text on a web page? Dive right in! These are the sort of low-risk challenges that are great for expanding your repertoire a bit.
But what if your boss needs someone to fix the billing system? Maybe there’s an issue with the encryption keys that need to be rotated. If this is done incorrectly, there’s potential for customer’s credit card numbers to be leaked. Should you put your hand up for this one?
Probably not.
It’s great to try to grow your experience, but be ethical about it. If you’re going to end up leaking sensitive data or causing downtime if something you do goes wrong, don’t do it!
Don’t be afraid to say maybe
It’s important to remember that if you’re the newbie in a team, you’re probably not the one making the decision. If there’s one of these high-risk, high-priority tasks on the table and you think you might be able to do it, don’t be afraid to admit that you’re not 100% confident when you volunteer. Be upfront about your skills and limits, and leave it up to your team lead to make the call.
It’s also worth remembering that there are plenty of degrees between “yes I can” and “no I can’t”. You can volunteer to act as second to a senior developer, or to have your work checked by the security specialist on the team, or something else that’ll give you the chance to work on one of these high-risk, high-priority tasks.
If you feel it’s better to be saying no a lot, you might end up being a specialist in one thing — not that that’s a bad thing!
Focus Areas and How To Find Them
Be a specialist at one thing
You don’t have enough hours in they day to learn everything about everything. Instead, decide to be the best at one thing. Maybe at your work, you’re aiming to be the person everyone goes to for React help. Perhaps you aim to know everything there is to know about Python, optimising functions faster than anyone. Or, maybe when there’s a CSS box that just won’t centre, you’ll be the one to know exactly how to fix that.
Whatever it is, decide you’re going to own it, and then do your best to be the best – even if it’s just inside your company, team, or scrum group.
Know a little about everything
Like or not, any software system is made up of multiple parts. There will be experts in each domain, but you shouldn’t be oblivious to the pieces you don’t touch.
Say for example, you’re developing a mobile shopping platform, or more specifically just the frontend mobile app.
You should aim to be capable of explaining the broad strokes of what happens when a user performs a product search, and know enough to fill in the background details:
A search request is sent using an HTTP GET request to our backend.
What happens if I search for weird HTML characters?The backend server queries an SQL database.
What database is used, and why?A full-text index is used for the retrieval.
What advantage does this have over just usingLIKE?The data is JSON encoded.
What if there is JSON in some of the values themselves, how is this handled?My app decodes this and draws the results.
Should we make considerations about very large numbers of results?
And so on!
You don’t need to be an expert on everything (there’s only so many hours in the day), but knowing a little about the entire stack can help guide your decisions and know the right questions to ask when you do need help.
Project Requirements: working the system
Follow requirements exactly
Big corporations (and even small ones nowadays) have specific roles that have very narrow focus for their roles. Business analysts come up with requirements for you to implement, UX developers tell you how to make it look pretty, and the coders implement it all.
Once you have the behavioural and design requirements, the easiest thing for you to do is follow them to a T. Even if certain elements don’t make sense to you, there’s probably a good business case for them. Sometimes, as a developer, the easiest thing is to just do what you’re told.
Question requirements that don’t seem right
That being said, as a developer, you should also know what limitations there are to your system when compared to the requirements. Sometimes it’s good to think in terms of the Pareto principle, also known as the 80/20 rule. Although some of your decisions won’t exactly match this ratio in terms of effort and output, you can think of this generally as “we can put in a fraction of the effort and still achieve most of the desired result”.
For example, say your system is required to have 100% uptime, which means literally no downtime. You now have to start thinking about multiple redundant servers in different regions, with load balancers to forward traffic between them. This starts getting expensive – fast. Not to mention, the added complexity to development. You need to be careful with database migrations to make sure they don’t take too long. Table addition, removal or change needs to be done in the correct order along with app code deployments.
If you are able to drop down to just 99.9% uptime that gives you 10 minutes per week to take the app down, do deployments and bring it back up. It doesn’t sounds like much, but it’s an eternity compared to 0 minutes.
There might be other constraints that are near-impossible to overcome without massive infrastructure investments. The requirement writers are probably not aware of these, so it’s your job as a developer to speak up when necessary.
Learn the logic behind the requirements
This leads to an important point: the requirement writers aren’t always right. They may have reasons for those requirements, but whether or not they’re good reasons is a different question. If that company which wanted 100% uptime is, say, a high-frequency trading company, those 10 minutes’ downtime per week could equate to hefty fiscal losses. If it’s a sporting-goods store on one continent, then perfect 100% uptime is an unnecessary requirement.
What’s more important is that there’s a thought process behind the requirements of any project, and understanding that thought process is valuable. It can help you either fulfil those requirements more closely, or help you suggest changes that get the clients what they want. So don’t be afraid to ask your peers this simple and diplomatic question: “How does this benefit the client?”
Conclusion
It’s understandable if all of this comes across as contradictory, because it is; there’s no one-size-fits-all set of rules to follow when it comes to the job. So much depends on the context, the co-workers, the contract, and a hundred other details. Maybe you’ll end up with a senior dev who’s a misanthrope, or a corporate culture that consists of “shut up and march”.
Tera Shift prides itself on having an open and welcoming dev culture that brings out the best in us, but we know that bad experiences can leave you unwilling to put yourself out there again.
In practice, all of this advice can be summed up pretty simply: put your best foot forward. Know the limits of your comfort zone, and then push yourself past them. Demonstrate your willingness to contribute to the team, and give your team the opportunity to contribute to your development, because often they’ll be happy to do so. Just be the best dev you can be, never stop learning, and you’ll do just fine.