I’m a software developer for long. Approaching a magic number once again, I started to ponder what lessons I may have learned. Others might have their own story, but I have my own perspective too. Here’s is a list of the things I wish someone would have told me before I jumped on the software developer bandwagon.
Nobody teaches you how to apply things in practice
Because they can’t. No matter how sophisticated use cases your educators come up with, you’ll still be alone facing problems when you get hired by a company. They hired you to cope with such challenges, and not your mentors. And those challenges are peculiar to that situation. Of course there are patterns and best practices, but that’s not the point. You’re yet to learn how to apply them in situations that are different from the textbook examples. You may meet with obscure specifications from product design teams, who themselves don’t know what they are doing, yet you’re expected to implement them. Misconceptions are so common, that you may develop a blindness to it. And on top of that, the requirements are ever changing. So no chance anyone can prepare you for that. Which also means…
Compromise is the name of the game
So you learned all the good stuff, and developed the cleanest hobby projects on your own? Great! Say goodbye to them. From the time you get hired, or you start your own business, you will need to work with others. Others may not share your ideas about how it’s best to approach things. In fact they most likely won’t. Those ‘others’ can be fellow developers, managers, clients, you name it. They all have their own idea, and you can’t change their behavior. You can only change your own. Which you’d better do, because success requires certain amount of flexibility. Better bend than break.
If you are willing to revise your approach, others will appreciate it. If you stick to your own ideas no matter what, they will hate you. Be warned! Even if you achieve to get extremely unpopular, you will still meet with forces you cannot change. A stupid client, a neglectful colleague just to get started. Third party code also can betray you. Imagine you find a bug in one of the libraries you are using, which is extremely difficult to be fixed. What if something you relied on reaches its end of lifetime? What if two great software components refuse to play nice together? What if time pressure takes you toward quick and dirty solutions? You will need to compromise. This happens all the time, because…
Programming is not exact
We learned math, and have the impression, that it’s strict, it’s formal, everything is well defined, everything is specified, it works according to laws and rules. We tend to think programming as a direct consequence of that. Math run on computers. Not quite. You better think of it as a bin of mixed Lego bricks. Each brick is formally defined, and produced accurately enough, to fit together with other pieces perfectly. Yet that doesn’t prevent us from building a pile of garbage out of them. You can combine them so many different ways, that plenty of them gives poor results.
You can even bend some pieces, or create 3D printed replacement parts on your own. The more you rely on custom parts, the less likely you can combine your product with the ones made by external parties. And the more likely developers, who inherit your project, will curse you. And you can inherit such code yourself, because…
Most developers don’t know it either
Have you ever felt taking a course, where the presenters themselves don’t seem to know the topic much better than you? Have you ever felt that you could have just as well read the documentation on your own instead of listening to them? Have you ever asked questions on which the given answers proved to be wrong? I have bad news for you. Most developers don’t know it either. At least not better than you. Most certainly nobody knows your problem better than you. Maybe they used a different version. Maybe they never knew. Maybe they didn’t have time to dig deeper. Maybe you misuse your tools.
You can wait for the next book on the best practices, or you can polish your question asking skills, but either way…
You will be often left alone
You approach your first job with high hopes from all aspects. One of them is that you will learn a lot from your senior colleagues. The thing is, they are super busy with other stuff, and they don’t really care about your education. They don’t trust you anyway. They will only give you small responsibility tasks, with low risk of failure, that they consider trivial, and regret spending their own precious time on. This is their best interest, and you will do the same if you persist. So maybe they simply don’t care. Have you heard that they let you to take ownership of what you’re doing, and take responsibility of your choices? That’s what they mean. You will have to clean up your mess anyway (or the next victim).
You may also have colleagues who are not senior to you. They hardly received the same education as you, and even if they did, they hardly put their focus on the same things as you. And they will have their own problems, because you’re not hired to work on the same tasks together. That means they also won’t care much. But that’s not the worst! They could just leave you alone in your misery, until you find the light at the end of the tunnel. But there’s worse! Some are 100% sure they know it right, although they don’t. Or even if they are not sure, that doesn’t prevent them to give you advice. Especially if you go for it (Stack Overflow anybody?). On top of that, they can misunderstand you. And maybe there’s no answer to your question at all, because — believe it or not — you can be wrong either, asking the wrong question all along.
Maybe you’re too proud to admit you need help. Anyway, you’ll be left alone often, and help resists to come, and asking does not mean getting a response. You know why? Because if somebody can answer your questions properly, can also do your job. And in that case they’re better off doing their own job instead. Which they do, so they have their own motives to help you anyway, because they know that…
Staying afloat requires continuous effort
Sorry, if it starts to feel like a collection of bad news, but expertise does not happen automatically. You need to put enormous effort into that. In fact even staying afloat requires continuous effort. You can stay a mediocre developer, or you can even decline professionally, and go back to the small rural hardware shop you started in. You don’t understand the latest trends? You can stay with the older ones provided you know them better. But to be useful to others (which is the essence of getting hired), you need to know something very well, which does not happen overnight, and requires effort. And by effort I mean: doing daily business gets less and less effort over time, but its value also decreases, because you may do the same thing all the time, but that may not be the best, and may not be needed anywhere else that much (if at all). So you better learn new stuff as well, even if it’s a 10+ years old framework, that somehow still hosted in some places whose owners are desperately looking for developers, you need to know it very well, especially because you don’t want to fight with mythic monsters during your work, but you want to solve problems to your employer. No matter how, you will need to put extra effort into learning stuff, because your job may not provide enough challenges for you to develop. And not having challenges is comfortable too. But then it happens that…
Trends can frighten
You have a look at the latest PHP or jQuery trends on Google, and they look like slopes of a volcano. Cold sweat hits you, because that means they have been declining for ages, and it may come the time that nobody uses them anymore. If nobody uses them anymore, nobody will hire you. If nobody hires you, how can you afford to buy that Siamese fighting fish, you’re longing for because it’s so undemanding, it could even survive your patronage?
Or maybe your company is using an old technology, but they cannot upgrade it, because the dependency graph is so delicate, the whole application can collapse if the versions are not restricted. Others are talking about the latest and greatest, cutting-edge technologies, according to the trends and hypes and having fancy, shiny websites, that look cool, while the one you use has a txt file hosted by an Apache server in its webroot, and rendered with monotype font by the browser. Such a shame!
Or you bet on the wrong horse, and that fancy-shiny project was shut down one year later after you learned it all by heart, and sent uncountable pull requests to their repo. Bad luck! Not only nobody cares anymore, but also nobody supports that anymore. You can choose between taking it over, like a heroic Don Quixote, or from thereon deny that you’ve ever seen it.
Before you get a heart attack from unexpected turns in software trends, you can find your peace of mind and inner calm, because…
Things change slowly
Relax! Take it easy! (May the earworm be with you.) The more some software products were in use, the less likely they just disappear. It’s like gravity. Your rocket targeting Mars either escapes or falls flat. The same applies to software, where the jet engine is the marketing behind some believably usable features, and the escape velocity is determined by how many companies adopted it carelessly. Just kidding. But the more real projects are using it, the more likely it will hang around.
Also more likely that developers who didn’t bother to master other things as well will defend and advocate it by all means. Which may be alright. Maybe they will come up with some cool new features that saves it. A revision that changes everything. It happens more often than not. For an extent. And mitigates the misery of the desperate developer.
Seriously, there are older software around than you might expect. Which causes phenomena like the one that Cobol is still demanded even lately. Or the comeback of Fortran. And by comeback, I mean coming back to be the top 20th of the most popular programming languages! We’re talking about 60+ years old languages here stubbornly refuse to go extinct. Younger languages you may mourned after school, like Delphi, are just fine. So fear not, your beloved script language may also survive.
We tend to think about technology as something that evolves — and therefore also changes — quickly. This, however, does not mean that it won’t last long. Some things don’t stand the test of time, while others ripe to be mature, battle tested and proven. It would be foolish to drop those just because they are old. There’s enough place for slowly changing programming languages and technologies as well.
The slower it changes, the more reliable it may be. There are things that change faster than software version numbers, and even that don’t mean much, because…
Fancy office does not mean quality code
Nowadays you can get eye candy templates to kickstart your website for free. This is because they are meant to launch your online presence. They are ready made, so that you can focus on more important aspects of your business. That is the minimum. Yet we tend to think that an eye-catching website is a telltale sign of a quality product. No, it’s not. As mentioned, that’s the bare minimum, if you want to raise awareness. However there are cases when you don’t need to raise awareness. Look at for example the most popular programming language according to the TIOBE Index. C doesn’t even have a website!
Here’s how one of its compilers’ website looks like:
Here’s another one:
They look like that to scare you away. Compare them with the Groovy website for instance:
Yet C rules the world, while Groovy… we love Groovy too.
And then you look at that gorgeous office of the company you’re about to apply to, and you picture yourself a stack of high-quality, beautifully structured and immaculately clean code. Until you see it with your own eyes, that is. I’m not saying it can’t happen. Or about the chances of finding it right. What I mean is that there’s a significant chance, that you will find the same state as everywhere else: a lot of compromises, a lot of solutions driven by necessity, considerable inconsistencies, unimplemented features, unfinished refactorings, innumerable workarounds, quick and dirty fixes, God forbid hacks! How dare I claim something like that? Did I work everywhere, to say it for sure? Nah, they tend to make them opensource anyway.
However judging other people’s code is not the point. I’m pretty sure they had well established reasons to do so. I may risk to say they did their best to achieve that state. They strove hard to get on that level. It’s not that they were negligent. This is how it works. Hardly anybody else could have done it better. Even if their best developers don’t shift roles, which they totally do…
Business is not business
And then you end up spending five years at one company. People come and go, but you persist. You know the code like the palm of your hand. You worked with every hidden corner of that repository. Hardly any piece left that you haven’t touched yet. You are the number one go to destination, if anybody want’s to know something about the application. They appreciate it. Eventually the management will say, you know so much that you’re preferred to share it. You’re the one to tell how to approach any questions related to development. Newcomers are straight forwarded to you. You prepare introductions, development environments, presentations. You’re asked about candidates. You create application assets, tests, interview questions. You decide who to be hired. You soon to manage your own team!
New project can’t be started without you. You discuss the possibilities with the product engineering team. You become system architect to build new projects from scratch. You run from meeting to meeting. When was the last time you ever touched some code?
I actually sketched two different paths here. You may proceed into education, or team management (usually mixed). You may create documentation, write blog posts, even a book. Create Youtube videos, courses on Udemy and the like. Or get overwhelmed with managing your team, hire new members, organize workflow and prioritize tasks. You become responsible for cross-team communication, and often audited by the chief executives. You may have problems with your colleagues whom now you need to manage like resources the most effective way possible to achieve optimal performance. But there’s one problem. Copy and paste didn’t teach you how to deal with people.
Like it or not, these are completely different roles requiring completely different skill sets. Social skills are key in this new role, but were marginal in the previous one. Formerly you received your tasks organized by somebody else, now you need to organize tasks for others. When did you master that? There are methods according to which it’s worth channeling work processes to provide unobstructed flow. Otherwise it can happen that it feels like sticking duct tapes on leaking pipes. And that’s understandable, because it’s completely different from what you’ve done before. Yet, it may come the time when you cannot advance your career anymore without shifting roles.
And with new responsibilities come new challenges you’re not used to. For example, how to negotiate, how to reconcile conflicts, how to motivate people, how to provide and receive feedback, etc. So why do they expect you to excel in that too?
I can’t tell you why. But I can tell you it’s a more common scenario that it ends up in accumulating problems than we’d like to admit. It simply doesn’t make sense that you become proficient in one role, and they reward you with another one. This business is not that business. Teaching and mentoring is not coding. It can be perceived easily as condescending. Especially it others are envy on you. Writing is also not programming. There are more words than keywords. Managing people is nothing like implementing new features. They may fight their own crusades. Did you manage to track down that pesky bug? Then sure you can cope with some badass developers torturing each other driven by their overheated ego, innit?
Similarly, if you dream about writing your book, then start reading books first. Then write something, collect topic, book ideas, challenge your thoughts on a regular basis. I’m not here to tell you how to do that, but I can tell you it’s slightly different than being a good developer (although it definitely needs some overlap as well). On the other hand, managing people requires people skills. You most likely either already have them, or will never learn, because it’s not something a textbook can teach. What it can teach are the methods you can use to organize work and resources for maximum efficiency while you’re still using your innate soft skills with people all the time. And they can be annoying too. If you want to be a manager, go for it. I’m convinced that it will be better for you right away, and you don’t need to sit through years of coding. And if you enjoy programming, then think twice before you change roles to advance in your career. Maybe it’s not the future you ordered.