Harsh Truths I Learned As a Junior Developer
Originally published at https://oprea.rocks/blog/harsh-truths-junior-developer/
A lot of mixed feelings may grow on you while working as a junior developer. You have the choice of feeling powerless and less smarter than your peers or full of energy and desire to learn from people who know more than you do. You can look at others, compare yourself to them and grow frustrated, or look up to them and strive to become a better version of yourself.
A bit of backstory
As some of the readers of this blog know, I’m a self-taught web developer. I have formal education, but I pursued that once I was well into my software development career.
I didn’t follow the regular, high school>university>internship>real job path many of my peers went on. Because of what I studied in high school(philology) and my first two years in university(kinesiology), I can’t say I could follow that path.
I was also a total ignorant.
For the most part of my beginnings as a web developer, I took crappy “jobs” from sites like freelancer.com, odesk.com (that later merged into upwork.com) and similar cheap-gun-for-hire sites. I’m not bashing these sites, they were and still are a good option if you need something to get yourself going on the freelancing path, or to just keep the lights on. Don’t dismiss them.
As for the jobs, I really took the crappiest ones — literally working a full day, for $20 on some CSS.
But that’s what shaped me into who I am today, and what made me both resilient and competitive.
I learned a lot of things while freelancing. But you learn the hardest truths about yourself and your craft when you’re working alongside other people. That’s when competition is more than you racing with some invisible person from India and another from Germany, for the next project. It’s when competition is more physical, visibly present.
It’s when your inner ape 🦍 starts showing up and when you start learning a lot about yourself and others.
Full disclosure, at my first real job, I was hired directly as a mid-level JavaScript developer. That’s because I had more knowledge about the language — in theory — than my peers at that company. But as soon as the rubber had to meet the road, it was hell to pay for me.
I felt like a total fraud.
What follows is a list I compiled, with the “truths” I learned, in my first year as a junior developer.
Nobody cares
You might think people care about who you are, and what you stand for. They don’t. They will respect you, because you’re a human being, but your JavaScript skills don’t command any extra respect. Don’t expect it.
I made the mistakes above, and once I realised what I was doing, it felt like crap.
You also don’t need to prove anybody anything. Well, except for your managers, who are closely watching those KPIs(Key Performance Indicators). I really hope you work for a company that has realistic KPIs.
The only way to prove anything is by doing and by helping others do. Building people up is the best way to make yourself known and make sure you have a positive impact.
I was neither worse nor better
I really thought I knew JavaScript. I had that theory down 100%! I was on point with my array methods, I knew about event delegation, prototypal inheritance.
I had no fucking clue how to tie all that knowledge together. It was knowledge I acquired in the two months prior to the interview, just because I set myself out to consume everything I could about JavaScript and DOM programming.
I knew a bit of both, since I was working with web technologies for almost 4 years, at that time. But I never took on challenging projects, on the JS side, by that time. I was beginning to get complacent, and with a newborn on the way, my “freelancing” did not cut the mustard.
Yet I thought I was smarter than my peers. I wasn’t! And you shouldn’t get into a job thinking you’re the smartest one in the room. If that is the case, you either need a different attitude or a different room.
Stop comparing yourself to others
As soon as I settled into my job, and realised my shortcomings, I started picking “competitors” and comparing myself to them day-in and day-out.
That’s not healthy, at all!
Some might say that’s not the characteristic of a healthy person, but I believe such virgins are full of it!
As smart apes, one of our first instincts is to identify the dominant apes and see where we sit, in that hierarchy. Unless you haven’t noticed, we live in a dominance hierarchy. Actually, many of the small “ecosystems” that surround us are dominance hierarchies at a micro level.
This makes comparison almost inevitable.
Just as inevitable as the imposter syndrome or its counterpart, the Dunning-Kruger effect — special thanks to @mmschneerson for pointing out the confusion. Once I saw that I wasn’t as smart as I thought I was, I panicked. I felt like a fraud. Every day I would fail to deliver on a damn jQuery plugin, or some requirement that was supposed to be meaningless, by my standards, I would fret and hyper-ventilate.
That’s why I went into monastic mode and started learning even more. Turns out that they were treating me just as they would treat any member of the team. The difficulty of the tasks I got was either at the level of the whole team, or sometimes even more difficult, to push me out of my comfort zone.
But with the help of the decent human beings on the team, and my theoretical knowledge, I managed to get those delivered within decent deadlines. At least that’s what my manager told me during my first and second review.
That’s when I realised I should only compare the current and previous version(s) of myself.
That’s the only way you will be able to measure progress! Because your previous version isn’t trying to outgrow you. It will stagnate, in comparison to your current self, so it’s easy for you to see progress.
On the other hand, if you compare yourself to your peers, you’re in muddy waters. As you grow, they grow too, so there may not be not much of a difference between you and them. And this is when it gets nasty, because you want to see progress in yourself. This is when you start looking for flaws in your peers, when you start nitpicking, and that’s even more twisted.
Bottom line, don’t compare yourself to others!
Go do! Theory is useless, without practice.
If you’re a software developer, unless you want to become a teacher, you need to do a lot of software development. This means writing a lot of code.
But just as important as writing is, you will also spend a lot of time reading other people’s code. Being part of a team means you will do code reviews, evaluate libraries, or go through a piece of legacy code and document it, as an initial contribution. To train your “eye” when looking at other people’s code, you can pick your favourite JavaScript library and do a code review of it. Just read its code and try to understand the functionality it provides.
Bonus points if you start reading a book like the GOF book and try to identify the design pattern(s) used in that library. That alone will get you far in life, as a developer.
You will underestimate work!
Precisely what the heading says. It amazes me that to this day, I still can’t provide accurate estimates in more than 65–70% of the cases. And I’m over-estimating this time, too.
As precise as software development looks like, from the outside, let me tell you this: It is not!. There is a lot of creativity involved into picking the libraries, making sure they add up to the final solution, read through documentation if there is any, read through API code if you don’t have docs. There’s also mixing and matching all sorts of libraries and tools, watching out for the design and the acceptance criteria and add a bit of bells and whistles of your own.
You should know that estimates are just what the word says. Estimates, projections, placeholder timeframes. As long as you’re diligent about communication, letting your manager know that one task will take 3 days instead of 1, is a lot more valuable and less frustrating when you’ve spent two hours on that task. Less than telling them it will take 3 days after the 2nd day of work has passed, when you said it would take you 4 hours.
You will overestimate your capacity!
There are only so many tasks you can take on. Nevertheless, you will sometimes go into Superman-mode and think you can fix that production bug that’s been rotting in the task list for the past 3 months. You will also think you can simultaneously deploy the app to production and deliver two other features on time for the client to present at a fare.
You won’t be able to do it without a lot of sacrifice. The problem is that it might go unnoticed since you said you can do it. Nobody asked you for heroics, so why should you get special attention?
Anyway, if you already said “yes”, see how you can let that person know you made a mistake. When you do that, also come up with a solution. You can’t just say: “I can’t do it, find someone else”. They might have already set expectations with clients, business owners, etc.
Talk to your colleagues, see who’s willing to help, tell them about the problem, in as much detail as you possibly can. Then go to your manager and tell them about your mistake and how you plan on fixing it.
Good enough will do.
You won’t get a promotion if all you do is spend time polishing the invisible thing and only release it to your peers once it’s perfect.
It will never be perfect!
You know what they say: “Perfect is the enemy of good enough”. Work your way up to good enough and you’ll sometimes get to perfect, when you expect it the least.
Make work visible.
Always have your work “on display” for your peers and your managers to see. There isn’t anything a manager hates more than not knowing what the hell is going on. Especially when you have to manage business and client expectations, tight deadlines and a lot of other things that are invisible to the technical team.
Think of it like this: would you be able to work if you never knew what the hell the requirements were? If you were just fed a hint that you would have to dig for, for days?
You’d be scared the hell out! You would go into analysis-paralysis mode and over-engineer every piece of that thing you’re building, to account for every possible edge-case.
The flip-side is even worse — you deliver some crap that’s not even near what the client/business wants.
Fail early and fast.
Failure, especially if you’re just starting out, should be a learning opportunity. As long as you prioritise the basics and you don’t fail at writing an if statement, nobody will bat an eye. Even if/when you crash production.
They might make their code review process a bit more strict. But that’s you proving what things need to be improved, so more points for you, for that matter.
Try not to fail in the same way every time.
Failing and not learning is an indicator of lack of willingness to learn. Or lack of attention. A good tech lead will pay attention to those cues, and if you send too many such signals they will notice and take action.
Try to learn from your mistakes, look for feedback and also look for concrete ways you should be improving yourself. Everyone likes to give advice, and you’ll get plenty of that. You need a mentor who can help you find a solution. That’s a lot different since the mentor can also help you figure out a strategy to implement that solution.
Ask for details and time even when people urge you to make a decision
People will just walk by your desk, or send you an innocent chat asking for an off-the-top-of-your-head estimate. Don’t provide it immediately. Ask for details and time. 30 minutes will do, but just pause and think for a moment about the problem.
By focusing your resources at thinking about the estimate you will have better visibility into possible issues, remember past setbacks with similar implementations. Although the project manager will be very happy to tell the client you can deliver a feature in 2 days, don’t jus shoot from the hip. Pause and think for a moment. They may not like you now but they will thank you, later. You will thank yourself later.
Ask questions
Before you start working on some piece of functionality, pause and go through the requirements. Let’s say you’re implementing something that takes user input — a registration form.
- Are the ways the user will interact with the features obvious from the design/requirements?
- Are the feature states defined?
- What happens if there’s a system error?
- What happens if the user inserts invalid data?
- What are the validation criteria — input length, accepted characters?
- What does the successful state look like?
See how many questions can appear for a simple registration form? Make sure you read through the requirements and always formulate questions.
Stupid questions exist
I used to believe that there’s not such thing as a stupid question. There is! Don’t interrupt busy co-workers to ask questions you could easily find the answer to on Google or the official docs.
For example, I was recently interrupted by a co-worker. She was asking me how to duplicate a Confluence page I created. Just by typing “how to duplicate a Confluence page” gives you the correct answer in the top 3 results, on Google.
You might think I was an ass for not helping her, but this would have enabled her to come directly to me, more often. So I said I cannot help, and that she should Google it. She found the answer in 3 minutes.
There’s no such thing as multi-tasking
Unless you’re sending emails, updating Jira tickets, cleaning up your inbox or doing some sort of semi-automatic task, you won’t be able to multitask.
Software development is a complicated task. It’s cognitively demanding, like many of the so-called “knowledge-work” jobs, nowadays. When you get down to business, you start keeping contexts, complex data structures, scopes, call stacks and other relevant information in-memory.
Multitasking, and context-switching to be precise, have a detrimental effect on productivity. There is something called residual activation which keeps part of your attention trapped on the previous task. Even if you’ve completely switched contexts — different team, office location, project — some of your attention is still trapped on the previous task.
I like to think of myself as JavaScript. I can mimic parallelism, but if you want too much of that from me, I’m going to let you know that I’m single-threaded.
Learn to say “no”
If you have potential, and I’m sure many of you reading this article have, people will want you to do stuff for them. Just this one small change. Just that small tweak.
Say no! Ask them to prioritise the work and put it through the issue tracker. Ask whether you should de-prioritise something else to work on the new task. If it’s your manager and you can’t turn them down, you’ve now shifted the decision from you to them.
You go from “I’m going to take on this extra work and deliver on both my current task and this new task” to “please tell me how should I go about balancing task A and task B and which is more important”.
Take notes
This is very important, as it will help you have a clear mind without remembering everything that was said during a meeting.
Have a notebook near you at all times and make sure you write a lot of things down. You will get swamped by tasks, questions and colleagues who just want you to run something by you.
Writing things down at least gives you the peace of mind that you can turn back to your notes and they won’t disappear. Unlike the things you keep “in your head”.
There’s another aspect that’s really important. You need to review your notes and synthesize them. Mindlessly taking notes and not processing them will just be a waste of your time!
Bottom line
The bottom line is that you must be humble, and put your head down and work. That’s what I learned. Being a decent human being gets you 70% there. The rest is focus and hard work.
Keep an open mind.
Adrian.
