5 Big Lies Junior Programmers Are Told
By other programmers — and themselves
When you’re a kid, you’re told many things that you later discover to be absolute lies. The thing is, this process repeats itself: What might be true in your childhood doesn’t apply in college, and many things that may be true in college can be tossed out when you “turn pro.” Even then, there are “things people say,” like “Lightning doesn’t strike the same place twice.” When in fact, of course, it does.
Misconceptions about various aspects of the software industry turn out to be pretty difficult to spot and take apart. So many people fall for them, even if only temporarily — giving them a not-so-great start.
I hope this article, based mostly on my own experience, provides some useful insights. Let’s dive in!
Below are some statements many of us heard or inferred, which are lies. Of course knowing something to be a lie doesn’t automatically reveal the truth, so I’m here to give you my own two cents on these statements (which are lies).
1. If It Works, Don’t Touch It
Or the more common saying: “If it ain’t broke, don’t fix it.”
This may come your way when you break something while doing something viewed as insignificant, or when you suggest an improvement.
As you’re probably told in your own job, suggesting improvements is a good thing. If done correctly, it is — we’ll get to that later. But practically, more often than not, your input won’t be accepted at first. Furthermore, you may often feel like you get punished for good ideas. Don’t let that discourage you!
“It ain’t broke.” This is a lie, or a rather weak excuse. Generally speaking, no code is untouchable. As Jeff Atwood points out, although there are many metaphors for the process of software development, they all describe a process. No matter how good the program is planned, in real life, it evolves and changes. From refactoring bad design, to removing dead code and adding or updating comments. It’s part of its healthy life, otherwise the “garden” becomes unhealthy, ugly, and, eventually, dead.
Unlike projects at university, nothing is ever really “done.”
So no, the fact that the code works is no excuse for not making changes, even if useless functionality-wise. However, something else might be.
Ask why!
It could be a lack of tests for whatever reason which makes some changes problematic, or something else making it not worth the risk. Or, it could be that your code just isn’t that good. There are lots of good reasons for any initiative to be rejected, but you should get to the bottom of what they are.
2. Unshared Knowledge is Job Security
Or: Complex code is job security.
That one is often thrown out as a joke, yet, unfortunately, for some developers it’s actually a rather unofficial strategy for…job security, I guess. Nowhere (that I know of) will you find it as an actual suggestion, but the idea is out there.
So first of all, it’s a lie. Job security is a lie to begin with, as it’s often said, and not necessarily worth chasing regardless. But, with respect to knowledge, in most cases, companies don’t keep someone around just because they’re experts in some shady voodoo legacy project that everyone is scared of. Simply put, no person is irreplaceable, and if it comes to it, no module is either.
But even if it was true, it’s not like you’re not paying a price for your “security” if you go down that road. In fact, you’re missing out hugely. If you have any intention to grow and advance, in your company and professionally in general, one of the most productive (and fun) elements of your job will be sharing knowledge. It’s what makes your team effective, it’s often how you get valuable input about your own work, inspire and get inspired, and it’s part of what might eventually make you into the biggest go-to person. Also, to coin a phrase, when you explain something, you explain it to yourself as well.
Now back to the security point. You might still ask, and that’s where the statement comes from: “But if I pass on everything I know, why keep me here?” Because you’re good at your job, and as I’ve just explained, sharing knowledge is part of becoming good. In fact, trust me: You know more than you think, even if you’re far from the most experienced guy in the room. At some point there’s just not enough time to share important topics even in the most concise ways (as it should be — too much is not effective either).
Besides, your employer will always value your initiatives to share knowledge, as it’s a notoriously difficult problem to get people to do it more (not only in the software world). Let’s put it this way: The question you should really ask is: “But if I pass on everything I know, why not promote me?”
3. You’re in No Position to Challenge X
“You” as a beginner, and “X” being a person, an idea, a policy, product decision, and so on. Another way to put this is, “Don’t be the troublemaker.” Spoiler: It’s a lie.
Probably no one ever actually said that to you. But, especially as a junior, you’ll get a sense of that resistance to whatever input you may offer, from small implementation details to “the way things are in here.”
It’s important to note that the level and nature of that resistance varies greatly between organizations, and between teams. But, it’s always there, and always will be. Accept it and learn to work with it. As I stated earlier, don’t let it discourage you. Even if it feels personal (which it probably isn’t).
The idea that you’re in no position to challenge, question, offer or lead a change, is a lie in your head. Someone might have put it there, but whether you accept it or not is up to you. Usually, the software R&D environment is pretty open to the exchange of ideas anyway. If your input is valuable and constructive, your lack of experience should be secondary.
There is of course a healthy amount of humility we all should have, as this post emphasizes beautifully. Driving change, big or small, is first and foremost about talking to people. People always know or see something differently, so there’s a lot to say about how to do it. But if there’s one rule I always had regarding speaking my mind it’s this: Be fearless.
Accept the likely possibility that you’re wrong and, if so, own it. That too is a big part of learning. You don’t have to accept anything as gospel and by speaking up, you may well say what others were thinking.
4. The Technology Doesn’t Matter
The world of software progresses on afterburner thrust, so having a variety of skills — platforms, languages and frameworks — is greatly valued everywhere. However, it’s easy to become confused with statements like “If you’re a good developer, the technology is secondary,” or that you should go with “The programming languages to learn in 20XX.”
I actually tried selling myself with that at job interviews (a long time ago…), as if I didn’t care what technologies the firm uses. And some part of me did believe that, thinking of it as the “correct” attitude.
Now, I’m not in a position to dictate anyone’s career path, however, I suggest you consider the following points:
- The technology you start with professionally has an impact on the direction your career will take. Do you want to focus on the back end? Then Angular (example) is not relevant to you at the moment. Does the world of big data speak to you? Then Python (example) is a great choice. The bottom line is this: do your research.
- Just because Swift overtakes Ruby in some survey at some point, that doesn’t mean you should switch to it today. Besides, learning too much at once is difficult and impractical. You need to focus on something and master it. Extensive experience with a specific technology is probably going to be a big part of your competence — and for many positions you’ll want in the future it’s mandatory. It’s great, and necessary to explore, but avoid the “Jack of all trades, master of none” trap.
- Not all technologies are equal in terms of opportunities, though. Let’s take programming languages as an easy example: You have the old giants like Java and C++, the rising stars like Rust and Go, and some dying stars like Perl and Objective C. Keep in mind, it’s very dynamic and somewhat subjective. But choose wisely. When you’re looking for firms to impress with seven years of Object Pascal experience in 2020, the technology isn’t secondary — you are. What will it be in the next few years?
It’s individual and not always an easy balance to manage — expertise and staying relevant. All I’m here to say is, don’t forget about expertise. At some point in your career, the technology might become secondary in some sense. But first, master something worthy.
5. A Workday is a Day of Work
Delays are bad. For you, your team, and your firm. Yet somehow, we never see them coming. What is it that turns something so seemingly predictable into an eternal unpleasant surprise? In short, naivety. A false mindset, that creates a bunch of small lies, which often obscure a simple truth: Everything takes time.
Everything, in this case, means everything. Every little task, like switching branches, compiling, reading emails, and ordering lunch. Everything includes a bunch of stuff you almost never account for.
Take this trivial feature: You need to provide a function that executes a script. That’s it. If you think it’s a one-day thing (what we call a “quick win”), say, without meetings and interruptions, bear with me:
- 10 AM: Start counting the holes in that “requirement.” What do you do with errors? Or the exit value? What about if we get stuck — is there a timeout? A configurable one? Do you need to intercept the output? What if it’s huge? You get my point: The first issue will be getting actual requirements. You probably need people for that — so you go look for them. Half a day has gone. Lunch.
- 2 PM: While discussing the requirements, it turns out another project needs to use your function, so you can’t just put it in your project. Another hour of political debates about where to put it and how, then actually doing it. Plus a coffee break.
- 4 PM: Finally writing some code. And guess what, you’re done by 6PM! So it was actually a 2-hour feature, wasn’t it? Now, however, you need a testing environment. Day over.
- Next day: You have your testing environment by 10 AM, you write some scripts to test by 12 PM, you handle and test some scenarios by 14 PM, unit tests (not TDD, but just switch the order) by the end of the day. Tomorrow: Pull request, reviews, merge, and a little document.
The feature is in after three days of uninterrupted, fast-paced, and pretty smooth work. You can imagine that with interruptions and meetings it’s at least four, for a supposedly one-day feature. How so? Well, everything takes time. What we as programmers usually perceive as work is much less of the proportion of the actual work than we think, but our ego doesn’t let us admit it.
But you’re still going to fall for it. We all do. If there’s any suggestion at all I can leave you with, it’s this: don’t apologize. If there were inefficiencies you can address then do that, maybe, but it’s all work. Also, don’t extend your workday indefinitely (as I still do sometimes, unfortunately). Perhaps you’ll remember it if I say it again: Everything takes time.
Bonus: You’re Measured by Your Coding Skills
As demonstrated in the last point, actual coding is far from taking up most of our time and effort. Nor should it. After all, coding is not the goal, is it? Solving problems is . Once again I’m borrowing some wisdom from Jeff Atwood. It may be harder to see when you’re so busy bettering your skills at the dawn of your career and climbing steep technical cliffs, five minutes after leaving an environment where you were being measured so technically. But that excuse should get old much faster than you.
Now, “problem-solving” as a term in school (where you were five minutes ago) is kind of partial. It’s rather a “problem-solving training” — it’s kind of predictable. In real life, on the other hand, solving the same problems, again and again, is the last thing you want to do — and it’s not your job.
Your job is to solve them once and for all — big difference. And to do that, you need to identify them, assess them, question, plan, collaborate, initiate, investigate, communicate, adapt. All that with a positive attitude, utilizing experience, common sense, agility, and passion.
The skills that matter most, that you’re actually measured by, are far beyond technical. The only expression I can think of, that sort-of describes them, is one word: Professionalism. But that’s not all, since the goal is to solve the problem. The formula might look great, and still not work for reasons no one really cares about — because the goal is the result.
So, let’s put it this way: You’re measured by your professionalism, and how you translate it to results.
I don’t know about you, but to me, that sounds kind of liberating. Instead of chasing your own tail with technicalities that you don’t always care about, you’re actually expected to use your skills towards an actual goal. It’s almost like not being measured at all.
Conclusion
There’s no shortage of extremely popular ideas that aren’t based in reality. Discovering the less obvious ones, especially those that require a change in our behavior or attitude, may take some work. But that’s part of the journey — and it’s fun!
Thanks for reading!
