I originally posted this on my blog a couple of weeks ago. If it's interesting to you, I post new content on daedtech.com roughly weekly.
If you've followed me for years (and you read the title), you're probably thinking, "Erik, you hypocrite."
But let's not confuse everyone else with inside baseball just yet. There will be plenty of time to get into why I called them "junior developers" in spite of really disliking that term.
So give me the rope with which to hang myself, and stay tuned for my advice to those embarking on a programming career.
What This Post Is and Is Not
What I want to do here today is offer some tips. But if I just wrote a post called, "Tips for Junior Developers," I'd be, by my non-scientific making up of a number, the 79,667th person to write a post with that title.
And those tips would include things like:
- Be humble.
- Keep a developer journal and write down your mistakes to learn from.
- Read well-regarded books by prominent developers.
- Learn communication skills
I'm sorry, I need to stop. No offense to people who have written these things (including probably me at times). But I'm boring myself to tears just typing out the strawman.
So I won't write that post. I promise.
Instead, this post will have what readers of this blog and my book have come to think of as my personal spin on it, which generally ranges somewhere between hyper-cynical and coldly pragmatic, depending on your point of view.
If you've never read it, you might want to check out my definition of the corporate hierarchy, to understand what I mean when I describe people in organizations as pragmatists, idealists, and opportunists. That may prove helpful for perspective, since I'd characterize so-called "junior" developers (let's say people with < 2 years industry experience) as idealists by definition.
Those formative 2 years will determine whether you remain an idealist, graduate to journeyman idealist, give up and become a pragmatist, or... well, let's not worry about opportunists here. The intersection of budding corporate opportunists and people looking for junior dev tips is probably the empty set.
Career-Savvy Tips for Junior Developers
If you're embarking on a programming career, first of all, good for you.
Seriously. You've selected a path that will pay you handsomely and is, in my opinion, anyway, a lot of fun. I always thought of professional programming as "people pay me to solve puzzles."
As a so-called junior developer (or an aspiring one), you've come from one of two very broad paths:
- Recent grad with a CS or related degree, looking for that first corporate job.
- You have professional experience, but are making a career transition, perhaps with the aid of a bootcamp.
So you're either standing outside the club, leaning against the velvet rope and peering eagerly at the movers and shakers within, or else the bouncer has just waved you in, and you're telling yourself, "play it cool, play it cool!"
You've waited and worked for this moment. The club analogy trivializes it, because you don't spend months or years waiting to get into the club. (I mean, I don't think so anyway -- my days of going to anything called a "club" are so far in my rearview that I'd have to pull over for them to catch up.)
You're grateful to have that first job, and to be welcomed into the society of real software developers. I get it, I find your enthusiasm infectious, and I'm happy for you.
But don't let this excitement take your perspective. Because it will, and it does for most.
To understand what I mean, let's get into the tips.
1. Try to Avoid Jobs with the Title "Junior Developer" or the Like
The article I'd written and to which I linked in the intro is titled, "Junior Developer: The Title You Should (Almost) Never Accept." Spoiler alert: the "almost" is in there for when you have rent to pay and you don't have a choice.
Since I've written a whole post about this that you can read, I won't belabor the point here. Suffice it to say that "junior" functions as sort of a synonym to "probationary" in your title. As an official title, when an employer slaps it on you, they're saying "I don't trust this person to be competent, and neither should you, until we say you should."
And that's an awful lot of power to cede to an employer.
If the only job you can get (or the one you really love) comes with this title, then I won't tell you not to take it. But I'd suggest treating this as the equivalent of them not having a health insurance plan or paying below market.
There are plenty of jobs you can get where the entry level title is something like just Software Engineer. Take one of those, if you can.
2. Senior Developers: Trust But Verify
Speaking of titles that should stay in primary or secondary school, let's talk about the seniors. When I took my first entry level job, back during the American Civil War, I remember being kinda star struck with the software pros working at that company.
I'd been in the workforce for a week. Some of those folks had been doing it for 20 or more years. Wow.
Looking back on it now, those folks were, genuinely, software pros. I definitely learned a lot from them and I remain grateful to this day.
But were they some kind of programming royalty? Nah.
They were getting the job done, and competently so. But my breathless admiration said more about me than it did about them.
And this misplaced admiration happened in a shop where the senior developers were good at their jobs. There are a lot of places where this isn't true -- where the seniors are really just what I call expert beginners.
So as someone new to the workforce, realize that there's a good chance you'll learn a lot from the senior engineers there. But, whatever you do, don't assume that they're infallible. They're definitely quite fallible and they might even be quite flawed.
3. Ask for a Lot of Help While Everyone Still Expects That
Speaking of the junior-senior dynamic (and remembering that we're actually not talking about high school), understand that people will expect you to ask lots of questions. They'll even encourage it.
But this won't remain true forever in your career.
Personally, both as a people manager and worker, I think everyone should always ask lots of questions. But this is a post about realpolitik advice, and, sadly, not everyone thinks this way. In fact, a depressing chunk of the workforce views asking questions and asking for help as signs of weakness.
As a "junior developer," you're already in an office-political position of weakness. So take full advantage of that to ask as many questions and for as much help as humanly possible.
Solicit every opinion about everything from everyone in your group. Ask people to review your code and pair up with you. If you're struggling with a design pattern, framework, or architectural concept, ask someone to whiteboard it for you.
Help from others is extremely valuable, and it won't always come as cheaply as it does right now for you. So buy in bulk.
4. Understand that the Software Org Chart is Way... Weirder... Than Every Other Org Chart
People in software have a unique penchant for stack ranking ourselves. As a group, we tend to believe that the entire software industry, consisting of 20 million people, could easily sort itself in order from "worst at programming" to "best at programming." Probably it's based on your Stack Overflow reputation (see the gamification section later).
As a result, companies have evolved to stand back in bemusement and humor us. What do I mean by this?
Well, consider that companies will have org charts that feature maybe 2 "levels" for other individual contributors. You're a "sales gal" or a "senior sales gal." You're a "social media rockstar" or a "senior social media rockstar." Anything above that, and you're probably in management.
But with software people? Pfft.
You have Software Engineer I, Software Engineer II, Software Engineer III, Software Enginer IV, and Software Engineer V. And then, when we run out of Rocky Movies to imitate, we start over with Senior Software Engineer I, Senior Software Engineer II, Principal Software Engineer I, Principal Software Engineer II, etc.
Software org charts can run 10 individual contributor positions deep, without the slightest sense of irony. And they also feature literally the only position in the corporate world that "we don't hire into."
So, understand going in that you're entering the org chart in a deep black hole of self-defeating weirdness.
5. Argue Your Positions with Support and Evidence
Switching gears a little, let's talk about how to stand out and eventually earn promotions. Or, if not that, at least how to win the day with your opinions and suggestions.
Specifically, channel high school debate club, and get used to using support and evidence to bolster your positions.
If you go to enough code reviews, you'll get used to argument by repetition and the loudest guy in the room 'winning' the argument.
- Tabs or spaces?
- Convention or configuration?
- To TDD or not to TDD?
All too often, teams settle these matters with "I've been here 20 years and I say so" or "arguing with Steve makes me want to die, so spaces it is."
You won't always carry the day, but you can definitely improve the discourse and tilt the scales in your favor. You just need to learn to support your arguments.
Find expert opinions, books, and whitepapers that align with your position (or revise your position if they don't align). Build prototypes to prove your point, when you can. Run time trials or create experiments that show your correctness.
Generally speaking, learn to counter the endless stream of opinions with "here's a few articles that support my position and, by the way, I did a proof of concept that shows I'm right."
6. Be Very, VERY Leery of Vanity Metrics and Career Gamification
Remember how, earlier, I planted my tongue in cheek and suggested that we could stack rank every programmer on Earth by Stack Overflow score? Well, Stack Overflow is a great example of a very, very sharp double edged sword in our industry: gamification.
Do you have 150,000 Stack Overflow points? Sweet! That's amazing! That and $2 will get you a soda at the gas station!
Here are a few other things you can also toss in with your $2 to help you get that same soda you could already afford:
- Github contributions every day for the last 365 days, earning the "iron-coder" distinction.
- Speaking at 20 user groups and conferences, earning the JFK Oratory award in your region.
- Writing a blog post on a community site every week for the past 52 weeks, earning the Walter Kronkite badge.
- Your employer's sincere and honest thanks for putting in 50 hour weeks instead of 40 hour ones.
Earning recognition feels good. There's no doubt about it.
But we in software have a unique and unfortunate tendency to elevate these things to goals in and of themselves, rather than means to ends. I've talked about this a lot on this blog, but if you're going to pursue something that takes a lot of time, effort, labor, and dedication, ask yourself why you'd doing it. Don't get caught up in pointless competitions and do it for the carnival cash.
7. Neither the Broader Software World Nor Your Company is a Meritocracy Because That's Not a Thing
As long as we're poking holes in weird balloons that the software industry inflates, like grotesque clown creations, let's talk about the idea that the industry is a meritocracy. If GigantiCorp hires someone and pays them more, then they're talented. If it pays them less or doesn't hire them at all, then they're less talented.
An industry that loves to stack rank itself with scores, badges and such, obviously presupposes that such ranking is rational. Boost all of your scores, learn your algorithms and data structures, ace your interviews, put in the extra hours, and the cosmic God of programmer stack ranking will see fit to reward you. Right?
Nah, not really.
As an industry, we can't even agree on what "good code" means, let alone define a way to evaluate it objectively. We tell ourselves that we reward performance, but we mostly just promote people for hanging around long enough not to get fired.
We disagree about basically everything in the industry, except that we all agree that our basic talent evaluation mechanism: hiring -- is broken.
So, yeah, the idea that getting "good" at programming will result in advancement and accolades? Nah, not so much.
8. Some Outcomes Are Better Than Others, But No One Even Agrees on What "Good Code" Means, Let Alone Embodies It
Let's drill into what I said about good code in the last section. Let's run through the articles that define "good code" and see what they say when they introduce the idea of "good code."
The first result in the search to which I linked meandered toward defining it this way:
The first thought that came to mind was maintainability — if it can’t be understood, maintained and extended by other developers than its definitely not good. Then, other things came to mind: efficiency, elegance (simple, proper use of language constructs and environment capabilities), modularity, proper object-oriented design, …
Good stuff, buddy. It means one of any number of things. Let's check the second entry to make sure everyone's in agreement.
We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, Law of Demeter - the list goes on.
Nice! It's a completely different set of terms than the first result. Let's check the third result to break the tie:
Good code is properly structured, as shown in the figure. It should be obvious for the person trying to understand code where a block of code starts and where it ends, so that following the logic of the code base becomes evident and straightforward.
Excellent -- I can see we have universal agreement here!
In case you can't tell, I'm enlisting a fair bit of sarcasm here. Google, "good code" and observe that none of the entries have the slightest bit of overlap.
This isn't to say that "good code" is some kind of nihilistic quagmire of relativism.
Taking less time to update than more is good. Code that invites fewer defects when touched is better than code that trips you up. Less code than more to do the same thing is preferable.
But disabuse yourself of the notion that there is some kind of universal definition of "good code." It's mostly just people yelling at you from a position of lots of anecdotal field experience and little empirical research.
9. Don't Learn Techs Just Because -- Have a Plan
Oh, here's a good one! Have you ever gone on a community site and seen someone say, "I'm going to learn {language/framework/paradigm} to make myself more rounded?"
I've been that guy. Both the one reading it and the one saying it. I remember once tweeting something like, "now I'm going to learn F# this weekend!"
But, do as I say and not as I do (did). Don't learn a stack/tech/language/framework just because it's there.
Oh, I know. It's easy to think, "but the industry is evolving in that direction, and everyone knows {tech}, these days. It's really just an investment in my future."
No, it isn't. Please believe me.
And now, I think I'll start learning F#
— Erik Dietrich (@daedtech) February 12, 2013
I've programmed professionally in probably 10 languages. Factor in persistence media, frameworks, etc. and I can't even begin to enumerate how 'wide' my experience is.
Have I benefited from that? Sure, I guess, to an extent.
But does each new thing I learn make me just a way better programmer? Do I have so much more wisdom and vision because I've programmed in Python (a language with significant whitespace) and C/C++/C#/Java/Perl/Assembly/Visual Basic/PHP/Ruby/Javascript (languages without it)? Was I enlightened by "wow, what if spaces were a token in a language -- mind, blown!"
There's nothing wrong with learning new techs, of course. But there's also nothing necessarily right with it.
As you progress in your career, you'll notice that a lot of programmers like to make their skill sets a mile wide and an inch deep by constantly learning whatever tech is newest. Resist this impulse. Keep getting better at what you've been doing unless you can articulate a plan as to how shifting gears benefits your career.
10. Algorithm Interviews and Interview Practice are a Race to the Bottom
You don't have to go very far into the programmer Twitter-verse before you find the "hiring is broken in software" tweet of the day going viral. And it always talks about the iconic "algorithm and dat structures" or "whiteboard" interview. But, likewise, you also don't need to go very far to find the latest set of wisdom for "cracking" that style of coding interview."
Why is that? Why the dichotomy?
Well, the reason that it's so prevalent is that what I call "Enterprise Silicon Valley" (so-called FAANG companies) lead the charge, and smaller, less established wannabes emulate them. Many industry participants thus put up with this, because, stupid or not, it stands between them and a prestigious employer.
But detractors criticize it because it's basically pointless hazing. Heck, the head of HR at the "G" in FAANG once described their interview process at the time as "a complete, random mess." Detractors are simply pointing out that, regardless of how badly you want into the fraternity, hazing is still stupid.
But let me offer you an oblique take here. Notwithstanding the merits (or lack thereof) of these interviews, they essentially cast you as a supplicant and the 2-year industry veteran administering the trivia as your superior. So even if you "pass" you still enter at the absolute bottom of a massive organization, having just gone voluntarily debased yourself a bit in a hazing ritual.
Understand that dynamic for what it is. Professionals don't let themselves get hazed.
11. Love Your Work, But Fight Anyone Who Uses that Love Against You
Years ago, I watched a video that I found revelatory. It was called "Drive: The Surprising Truth about What Motivates Us" and the upshot was that, more than money (after a certain minimum income threshold), we crave mastery, autonomy and purpose. We want to feel we're getting better, have the freedom to do good work, and feel that we're contributing to something larger, respectively.
This resonated with me, but I also observed that organizations tend to weaponize this against us. For instance, it's not a long leap from satisfying employees' desire for mastery to rewarding them with useless pat-on-the-back perks in lieu of additional compensation (see the gamification section, 6).
So for the last bit of advice that I'll offer, I beg you to be wary of this.
If your tastes run similar to mine, you'll find building software -- digital stuff -- is a lot of fun and it's rewarding. You'll also find that life is pretty good when you have a rewarding job that happens to pay quite well.
What more could you ask for?
Well, it turns out, sometimes a little, and sometimes a lot. Your company may pay you a lot, and you may love what you do.
But never lose sight of the value that you bring, and never let anyone convince you that loving your work somehow makes it less valuable. Don't accept statements at raise-time like "loving your work is its own reward," and don't confuse value-less perks and 'culture' with actual monetary consideration.
This isn't to say that you need to be in mercenary mode all the time, always haggling for every last dollar. If you're happy with your job and your compensation and everything else, then great! But make sure that not pushing is a conscious choice, rather than the result of someone bamboozling you by turning your own love for your work into a negotiating handicap.
Parting Thought: Have Fun
Office politics sucks. I'm well versed in it, having spent a lot of years in the corporate world, and then a number of years as a management consultant. I'm comfortable with it and quite aware of it, but don't confuse that with enjoyment. I wrote an entire book that aimed, in the end, to illuminate a career path that would minimize office politics.
But even though it sucks, and even though you may not want to deal with it, it exists. And if you don't "deal with it," it will deal with you, instead. So I wrote this post for new developers to create a sense of awareness with a different kind of advice than most of what you see.
And you need this awareness.
But don't lose sight of one key fact at the end of the day: You've chosen a career path that is exciting, that pays well, and that provides very rewarding work.
So understand office politics and the dynamics at play -- especially the particularly weird ones in our industry. But understand them just well enough to ensure that people don't take advantage of you. And then, after that, have fun with what I consider to be a great career choice.
If you'd like to ask a reader question, you can do so at the "ask me" page.
Top comments (6)
Wow! That's a great text. Thank you for share it.
I believe that each tip deserves some time to reflection before any relevant comment.
Thanks for the kind words!
Your section about the developer org chart reminded me about a half-baked theory of mine, so I might as well share here.
What if software is really a management track? Software development is kind of like building an entire shadow organization of bits and bytes, many times replicating and replacing human organizations. Every decision a developer makes changes this shadow organization.
Actual management also loves to have dozens of positions ranking all managers into a hierarchy, so it fits into my theory.
That's an interesting mental model, and it has some overlap with something that's historically occurred to me about software in large corporate org charts. Scientific management/Taylorism is the basis for the modern corporation's command-and-control, pyramid-shaped org chart.
But Taylor developed this model in the late 1800s to help line managers get more productivity out of factory workers, who his system regarded as sort of a hybrid between humans and beasts of burden. It was the precursor, sorta, to industrial engineering, and a system that worked well for orchestrating brainless labor, like drilling and cutting and whatnot.
But we've retained that model for over 100+ years, and it makes a terrible system for managing knowledge workers. I once compared it to putting on a puppet show by having a marionette puppet that, in turn, operated other puppets. Or, to put it another way, building a complex human org chart to direct complex knowledge work labor of systems construction really makes no sense.
Looping back to what you're saying here, I think my view is aligned with it. Building a software system, even if it's just a single indie developer working independently, is analogous to an 1890s factory line manager's work. So layering all sorts of other, human management on top of that gets pretty weird.
There's also a concept known as Conway's Law, which more or less says that enterprises will build software that's basically an architectural representation of their software engineering org chart. As someone who has consulted on a lot of codebase/architectural assessments over the years, I can tell you there's a lot of truth to that.
Man, that is very interesting. There is a lot more connection than I had thought then. So, how do we convince founders that software engineers are actually management and get paid accordingly?
I love the humor and the essential knowledge that comes with this pices. Thanks so much for sharing.