For a long time, writing code was the hard part.

You had to remember syntax, internalize patterns, fight the compiler, and slowly build an intuition for what worked and what didn’t. The feedback loop was slow, sometimes brutal, but it was formative. You earned every small win.

That’s no longer true.

Today, code is cheap. Abundant. Almost disposable. AI can write entire features, refactor existing systems, generate tests, and explain unfamiliar codebases in seconds. In many cases, it does this faster — and often better — than a junior developer.

This isn’t a prediction. It’s already happening.

And while most of the conversation has focused on what this means for productivity, hiring, or the future of engineering jobs, there’s a quieter and more uncomfortable question underneath it all:

How are junior developers supposed to learn now?

The bottleneck moved

AI didn’t just automate a task. It moved the bottleneck.

In the past, the limiting factor was writing code. Today, the limiting factor is understanding what the code does, why it exists, and how it behaves when things go wrong.

That distinction matters — especially for juniors.

If outputting code is the metric, juniors can’t compete with AI. And honestly, they shouldn’t try. That’s a losing game from day one.

But most learning paths, tutorials, and even job expectations are still optimized for the old world — the one where typing code was the primary skill to develop.

The result is a dangerous mismatch: tools that make it easy to skip the very experiences that used to build intuition.

How I learned (and why it mattered)

Years ago, I wrote an article called “An approach to learning programming languages.” The core idea was simple: learning a language isn’t about syntax. It’s about learning how problems are expressed and solved within a set of constraints.

What I didn’t emphasize enough back then is how much of that learning came from struggle.

Not heroic struggle. Not romantic suffering. Just… friction.

• Code that compiled but behaved incorrectly
• Bugs that took hours to isolate
• Refactors that broke things in subtle ways
• Patterns that only made sense after misusing them

I learned slowly. Often painfully.

I didn’t just learn what to write — I learned what didn’t work, and more importantly, why. That “why” became instinct over time. Not because I memorized it, but because I had felt the cost of getting it wrong.

That process wasn’t efficient. But it worked.

What AI changes for juniors

AI makes it possible — even tempting — to bypass that entire phase.

You can now:

• Generate working solutions without fully understanding them
• Fix errors without knowing their root cause
• Ship features without forming a mental model of the system

And here’s the dangerous part: this doesn’t fail immediately.

In fact, it often looks like success. The code works. The task is done. The PR gets approved. But the cost isn’t gone. It’s deferred.

It shows up later:

• When the system behaves unexpectedly
• When performance degrades
• When trade-offs matter
• When debugging requires intuition, not syntax

At that point, the gap is painful — not because AI was used, but because it replaced thinking instead of amplifying it.

Skipping the struggle has consequences

There are a few things juniors risk missing if AI becomes a permanent crutch early on:

1. Mental models

Without wrestling with problems yourself, it’s hard to build a clear picture of how things actually work. You can recognize patterns without understanding them — which breaks down fast at scale.

2. Debugging instincts

Debugging isn’t a skill you read about. It’s pattern recognition built from past failures. If you’ve never been lost in a system, you won’t know how to find your way out.

3. Taste

Good code isn’t just correct — it’s appropriate. Taste comes from seeing many bad solutions, including your own. AI can give you “working,” but it won’t give you taste unless you already have a baseline.

None of this means AI is harmful by default.

It means using it too early, in the wrong way, changes what you learn.

But let’s be honest: the struggle is real

It would be easy to stop here and say: “So just don’t use AI.”

That advice is useless.

The reality juniors are facing today is very different from the one I learned in:

• Faster expectations
• More competition
• Less tolerance for ramp-up time
• Constant comparison to AI-level output

AI doesn’t feel like cheating. It feels like relief.

It helps with impostor syndrome. It reduces anxiety. It keeps you moving forward. And when you’re trying to break into an industry that already feels hostile, “struggling more” sounds like terrible advice.

That context matters.

So the answer isn’t abstinence. It’s intentional use.

A better way to use AI while learning

Instead of asking “Should juniors use AI?”, a better question is:

What should AI replace — and what should it never replace?

Some principles that actually work:

Use AI after you form a hypothesis

Try to reason about the solution first. Even a bad attempt counts. Then use AI to compare approaches, spot gaps, or validate assumptions.

Ask “why”, not just “what”

Generated code is cheap. Explanations are valuable. Use AI to interrogate decisions, not just produce results.

Rebuild small things without AI — on purpose

Not everything. Just enough to stay sharp. Toy problems, utilities, small services. This is where intuition still forms.

Treat AI like a senior reviewer, not a generator

A good senior doesn’t write everything for you — they guide, challenge, and correct. That’s the mental model that scales.

The goal isn’t to slow yourself down artificially. It’s to make sure understanding keeps pace with output.

The new apprenticeship

AI didn’t eliminate the need to learn fundamentals. It made it easier to avoid them.

That’s the trap.

The juniors who will struggle most aren’t the ones using AI — they’re the ones who never learned how to think without it. The gap won’t show up on day one. It will show up when systems get messy, ambiguous, and unforgiving.

The path I took still works. It’s just easier to skip now.

And skipping it feels fine — until it doesn’t.

Throughout my software engineering career I kept hearing the word enablement thrown out a lot. Now, first of all, enabling someone to do something can have both positive and negative connotations. I think it’s only in this industry that it’s acceptable to say you’re going to enable someone. In any other context you’d get some weird looks just for saying that. So what’s special about an enablement team? Typically that means developing and maintaining components that other teams can benefit from.

If you ship software to customers you’re probably dependent on a continuous integration system. If it goes down, then you’re pretty much dead in the water. So someone, or a team of people, have to maintain it and keep it running close to 24/7. Can you imagine your company right now shipping without your CI system? If not, then the team that owns it is enabling you to do your job.

Gatekeeping is a word you don’t really hear much about. A gatekeeper is someone whose job is to not let anyone in to whatever they’re protecting. The CI team is on the hook for its availability, they upgrade it from time to time, implement new features, fix bugs, apply security patches, etc. Given that everyone in the company depends on their work, it’s only natural to expect that they will always have a lot of planned work ahead of them. It’s common in a lot of companies that developers from other teams may be interested in helping them even though it’s not exactly their job to do so.

Imagine you’re passionate about CI systems and you notice a problem with your company’s setup. It’s something you know how to fix, so you decide to just go ahead and do it. After you’ve prepared your patch for submission there are really two different scenarios that could play out, and they have to do with values. Let’s see how the next steps would play out given two totally different teams, A and B, who uphold different values.

You talk to team A and they accept to review your patch. They suggest some improvements based on their experience, and work with you to deliver it. You gain more insights into what it means to actually be on the team. You missed an edge-case and they point that out to you. You go back and fix it and re-submit, and your patch is finally accepted. They also let you know what’s coming down the road in the next months in case you find other issues.

You send your patch to team B. You don’t hear anything back for a couple of days, and decide to reach out in person. They tell you they’re swamped with work and don’t have time to look at your proposal. You keep trying to convince them that it’s a small fix which greatly improves developer experience, but they don’t want to hear about it and finally tell you flat out that it’s not your job to think about CI. You give up and go back to work. Six months later they fix the issue but you only find out about it by accident.

Team B is what I’d call a gatekeeper team, even though their official mission is to enable, just like team A. They don’t let people in if they don’t have to. This team rarely benefits from the expertise of outsiders. It’s basically like comparing proprietary to open source. But while I’m sure you’d rather interact with the former team, it may be useful to consider their perspective first before passing judgement.

It’s clear that team A values working together. If you bring an improvement to the table, they’ll take the time to review it, let you know if they were already planning on doing the same thing, or point out flaws in your solution. Team B assumes that since you’re not on the team, you really have no business thinking about their line of work and you shouldn’t even try. But is team B’s behavior objectively bad? Like in all things software, it depends.

What if team B is maintaining a critical banking software component? If you were in their shoes, would you be so eager to let outside contributors in? What if your improvement contains a bug? If that happens it’s not your responsibility, you’re not on the team. They’re the ones who have to fix it. Or perhaps their software is so complex there’s no way anyone on the outside would be capable of contributing without a lengthy on-boarding process.

You should also seriously consider that team A has to allocate time to work with you, so they’re making a call that you’re worth investing in. If it turns out your potential improvement would be a liability down the road, then they’re not getting that time back. It’s gone.

Team B in contrast is more draconian with their time. They consider themselves (perhaps rightfully so) experts in their field, and their assumption is, unless you’re on the team, you do not have enough context to suggest any improvements. You should only report problems to them and they’ll eventually get around to fixing them.

These are certainly extreme positions and I made them out to be so it’s easier to conceptualize. In reality teams are both enablers and gatekeepers from depending on the situation. But values always prevail, and it’s important to understand that when you need to work with other teams.

The word monorepo is a combination between “mono”, as in the Greek word mónos (in translation, alone) and an abbreviation of the word repository. A simple concept if taken verbatim: one lonely repository. The domain is software engineering so we’re referring to a home for source code, multimedia assets, binary files, and so on. But this definition is just the tip of the iceberg, since a monorepo in practice is so much more.

In this article I plan to distill the pros and cons of having every piece of code your company owns in the same repository. At the end you should have a good idea about why you should consider working like this, what challenges you’ll face, what problems it’ll solve, and how much you’ll need to invest in it.

The term itself, as visible in the chart above, looks to be as new as 2017. However it would be a mistake to think that previously nobody was storing all of their code in one place. In fact during my first job back in 2009, the company I worked at stored every project in a single SVN repository, one directory per project. Indeed you may well be able to trace this practice back even further. But how can we explain the recent explosive popularity, then?

The reality is that storing code in a single spot is not the main selling point. In the past years the major tech companies — Google, Facebook, or Dropbox have been showing off their way of working together within the same repository at massive scale. Organizations of tens of thousands of engineers collaborating within one repository is an awesome sight. And a difficult engineering problem. So difficult in fact that these companies invest a lot of money into tools and systems that allow developers to work productively. These systems in turn have solved problems that you may not even realize you had. This is what fascinates people during tech talks. This is what’s been driving searches since 2017.

• Front-end development at Google, Alex Eagle: https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe
• Google monorepo presentation, Rachel Potvin: https://www.youtube.com/watch?v=W71BTkUbdqE
• Scaling Mercurial to the size of Facebook’s codebase, Durham Goode: https://code.fb.com/core-data/scaling-mercurial-at-facebook/

I’ve identified a few core features that a Google or a Facebook vetted monorepo offers. This is surely not an exhaustive list, but it’s a great starting point. When discussing each of one of these points, I took into consideration what life looks like without them, and what exactly do they solve. Certainly in our field of work everything is a trade-off, nothing’s free. For every pro that I list someone will find use-cases that directly contradict me, butI’m OK with that.

All your code, regardless of language, is located in one repository

The first advantage of storing everything in once place may not be immediately obvious, but as a developer, simply being able to freely browse through everything is of great impact. It helps foster a sort of team spirit and is also a very valuable and cheap way to distribute information. Have you ever asked yourself what projects are in development at your company? Past and present? Curious what a certain team is up to? How have they solved a particular engineering problem? How are they writing unit-tests?

In direct opposition to the monorepo we have the multirepo structure. Each project or module gets its own separate space. In such a system developers can spend quite a bit of time getting answers to the questions I listed above. The distributed nature of the work means there’s no single source of information that you can subscribe to.

There are companies that have transitioned from a multi to a monorepo layout by following only this feature from my list. Such a structure should not be confused with the topic of this article though. I’d define it instead as a collocated multirepo. Yes, everything is in one place, but the rest of the features on this list are far more interesting.

You‘re able to organize dependencies between modules in a controlled and explicit way

The traditional, battle tested way of handling dependencies is by publishing versions to a separate storage system from continuous integration systems, or even manually, from development machines. These are versioned (or tagged) to make it easier to search later on. Now in a multirepo setup, each project has a set of dependencies of external origins (third parties) or internal, as in, published from inside the same company.

In order for one team to depend on another one’s code, everything needs to pass through a dependency management storage system. Examples of this are npm, MavenCentral, or PyPi. I said earlier that you can easily build a collocated multirepo just by storing everything in one place. Such a system is indirectly observable. Let’s examine why that’s important.

As developers, our time is split very unequally between reading and writing code. Now imagine having to debug an issue that has its root cause inside of a dependency. We can rule out third parties here, since that’s a difficult problem as it is. No, this problem occurs in a package published by another team in your company. If your project depends on the latest version, you’re in luck! Just navigate to the respective directory and grab a cup of coffee.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

More often though you might depend on an older version. So now what do you do? Do you try and use your VCS to read through the older code? Do you try and read the actual artifact instead of the original code? What if it’s minified, as is usually the case with JavaScript?

Contrast this with Google’s system, for example — since code dependencies are direct, as in, there are essentially no versions anywhere, one can say the system is directly observable. The code you’re looking at is pretty much your entire world. I say mostly because of course there are always going to be minor exceptions to this rule, such as external dependencies that would be prohibitive to host yourself. But that shouldn’t take anything away from this discussion.

While we’re on the topic of dependency management we should touch upon the subject of restrictions. Imagine a project where you’re able to depend on any source file you need. Nothing is off limits, you can import anything. For those of you that started their careers at least 10 years ago, this sounds like business as usual for the time. This is an almost complete definition of a monolith.

The name implies grandeur, scale, but more importantly, singularity. Practically every source file inside of a monolith cannot live outside of it. There’s a fundamental reason for this is relevant to our discussion: you don’t have an explicit and audit-able way of managing dependencies inside of a monolith. Everything is up for grabs, and it feels free and cheap. So naturally, developers end up creating a complex graph of imports and includes.

Nowadays practically everyone is doing microservices, there can be little doubt about that. Given sufficient scale, a codebase becomes a beast, as everything is inexorably linked to each other. I’m sure many developers will provide counter-arguments that monoliths can be managed in a clean, reasonable way without falling into this trap. But exceptions simply reinforce the initial statement. Microservices solve this by defining clear boundaries and responsibilities, and a monorepo is a natural extension of this philosophy. Typically modules offer a set of public exports, or APIs, and other modules are only able to use those as part of their contracts.

Software modules reuse common infrastructure

This is a topic that’s very near and dear to my heart. I’ll define infrastructure in this context, that of a software codebase, as the essential tools necessary to ensure productivity and code quality.

One of the reasons why I think betting your company on multirepos is a mistake has to do with a set of basic requirements any software engineering project should meet:

• A build system to be able to reliably produce a deliverable artifact.
• A way to run automated tests.
• A way to statically analyze code for common mistakes, potential bugs, and enforce best practices.
• A way to install and manage third party dependencies, i.e. software modules which are external to your company.

If you have your code split in multiple repositories, you need to replicate this work everywhere. Don’t underestimate how much work this involves! All of the features listed above require at the very minimum a set of configuration files which need to be maintained in perpetuity. Having them copied across more than two places basically guarantees you will always generate technical debt.

I know that some companies go to extreme lengths to minimize the impact of this. They’ll have their configurations bundled as scaffolding (a la create-react-app or yeoman), and use them to setup new repositories. But as we’ve seen in the section before this one, there’s no way to enforce that everyone’s on the latest version of these boilerplate dependencies! The amount of time spent upgrading each repository individually increases linearly in large codebases. Given sufficient scale, practically all published versions of an internal package will be depended on at the same time!

There’s a quote I absolutely love that relates to this conundrum:

At scale, statistics are not your friend. The more instances of anything you have, the higher the likelihood one or more of them will break. Probably at the same time.

— Anne Curie

If you think distributed systems just refers to web services, I would disagree. Your codebase is an interconnected, living system. Tens, hundreds, or thousands of engineers are racing to get their code into production each day, all the while struggling to keep the build green and the code quality up. If anything, to me this sounds even scarier than a set of microservices :)

Changes are always reflected throughout the entire repository

This is highly dependent on the rest of the features. It’s one of the benefits that’s easier to understand through example.

Let’s say I work at a company that builds web applications for customers all around the world. Everything is organized into modules, as is exemplified below via the popular open-source project Babel. At this company we all use ReactJS for front-end work, and out of pure coincidence, all of our projects are on the same version of it.

But the folks at Facebook publish the latest version of React and we realize that upgrading to it is not trivial. To be more productive, we’ve built a library of reusable components that resides as a separate module. All projects depend on it. This new React version brings lots of breaking changes that affect it. What options do we have for doing the upgrade?

This is typically where monorepo adversaries would shoot down the entire concept. It’s easy to say that we’ve worked ourselves into a corner and that the multirepo structure would’ve been a superior choice given the circumstances. Indeed in the latter case what we would do is just gradually adopt the new React version in our projects one by one, preceded by a major version upgrade of our core components module.

But I would say this creates more problems than it solves. A core dependency breaking change release creates a schism in your engineering team. You now have two cores to maintain: the new one, which is used by a couple, brave teams in a few projects, and the older one, still depended on by almost the entire company.

Let’s take this problem to a bigger scale for further analysis. Our company may have some projects which are still in production, but are just in maintenance mode, and don’t have any active development teams assigned to them. These projects will probably be the last ones to migrate, extending the time window in which you keep working on two cores at the same time. The old version will still receive bugs or security fixes even though it’s deprecated, as you can’t risk your customers’ businesses.

All of this is to say that a multirepo solution promotes and enables a constant state of technical debt. There are lots of migrations going on, modules that depend on older versions of other modules, and many, many deprecation policies which may or may not be enforceable.

Let’s now consider an alternative solution to the React upgrade problem. By having all of the code in one place, and dependent on each other directly, without versioning, we’re left with one option: we have to do all of the work upfront, in all modules simultaneously.

If that sounds like a scary proposition, I don’t blame you. It’s terrifying to think about, at first. However the advantage is clear: no migrations, no technical debt, less confusion around the state of our codebase. In practical terms, there is one obstacle to overcome with this solution — there may be hundreds, thousands, or millions of lines of code that need to be changed all at once. By having separate projects we avoid the sheer volume of work by doing it piece by piece. It’s still the same total amount of changes, but we’re naturally inclined to think it would be easier to do that over time, rather than in one push.

To solve this last problem large companies have turned to codemods — programmatic transformations of source code that can run at very large scale. There are numerous tutorials out there if you’re interested, but the gist of it is — you write code that first detects certain patterns in your source code, and then applies specific changes to it. To take our React example further, you could write a codemod that replaces a deprecated API with a newer one, and even apply logic changes if necessary. Indeed this is how Facebook recommends you migrate from one version of their library to the next. It’s how they’re doing it internally. Check out their open-source examples.

Viewed from this angle, a migration doesn’t seem as scary as before. You do all of your research upfront, you define how you want to essentially rewrite the affected code, and apply the changes more or less all at once. This to me is a robust solution. I’ve seen it in action, it can be done. It’s indeed amazing when it works and lately more and more companies are adopting it.

Drawbacks

The old adage of “there’s no such thing as a free lunch” certainly applies here, as well. I’ve talked about a lot of pros, but there are some cons which you need to think about.

Given that everyone is working in the same place, and everything is interconnected, tests become the blood of the whole system. Trying to make a change that impacts potentially thousands of lines of code (or more) without the safety net of automated tests is simply not possible.

Why is this any different from traditional ways of storing code? I’d say that versioned modules hide this particular problem, at the expense of creating technical debt. If you own a module that depends on another team’s code, by way of a strict version number, then you’re in charge of upgrading it. If you don’t have sufficient test coverage, you’ll err on the side of caution and simply delay upgrading until you’re confident the module doesn’t affect your own project. As we’ve discussed earlier, this has a serious long term consequences, but it’s a viable strategy nonetheless. Especially if your business doesn’t actually promote long term projects.

We mentioned the benefit of every contributor being able to access all of the source code in your organization. If we flip that around, this can also be a problem for some types of work. There’s no easy way you can restrict access to projects. This is important if you consider government or military contracts as they typically have strict security requirements.

Finally let’s consider continuous integration. You may be using a system such as Jenkins, Travis, or CircleCI, to manage the way your code is tested and delivered to customers. When you have more than one repository you typically set up one pipeline for each. Some teams even go further and have one dedicated CI instance per project. This is a flexible system that can adapt to the needs of each team. Your billing team may deploy to production once a week, while your web team would move faster and deploy multiple times a day.

If you’re considering moving to a monorepo, be wary of your CI system’s capabilities. It will have to do a lot of work. Simple tasks such as checking out the code, or building an artifact may become long running tasks which impact productivity. Google developed and runs its own custom CI solution, and for good reason. Nothing available on the market was good enough.

Now before you conclude that this is a blocker, I’d recommend you carefully analyse your project and the tools you use. If you’re using git, for example, there’s a myth going around that it can’t handle big repositories. This is demonstrably inaccurate, as best exemplified by the project that inspired git in the first place, the Linux Kernel.

Make your own research and see how many files and lines of code you have, and try to predict how much your project will grow. If you’re nowhere near the scale of the Kernel, then you’re OK. You could also make the point that git isn’t very good at storing binaries. LFS aims to solve that. You can also rewrite your history to delete old binaries in order to optimize performance.

In a similar vein, open-source CI systems are much more powerful than you think. Jenkins for example can scale to hundreds of jobs, dozens of workers, and can serve the needs of a large team with ease. Can it do Google scale? Absolutely not! But do you have tens of thousands of engineers pushing to production every day? The plateau at which these tools stop performing is so high, it’s not worth thinking about until you’re close to it. And chances are, you’ll know when you’re getting close.

And finally, there’s cost. You’ll need at least one dedicated team to pull this off. Because the amount of work is certainly not trivial, and it demands passion and focus. This team will need to, and I’m just summarizing here, build and maintain in perpetuity what is essentially a platform that stores code, assets, build artifacts, reusable development infrastructure for running tests or static analysis, and a CI system able to withstand large workloads and traffic. If this sounds scary, it’s because it is. But you’ll have no problems convincing developers to join such a team, it’s the type of experience that’s hard to accumulate by doing side-projects at home.

In closing

I’ve talked about the many advantages of working in a monorepo, the drawbacks, and touched upon the costs. This setup is not for everyone. I wouldn’t encourage you to try it out without first evaluating exactly what your problems and your business requirements look like. And of course, do go through all of the possible alternatives before deciding.

Essentials of monorepo development was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s a rare occasion that companies provide leadership training before you become a manager. A few days or weeks after what was probably one of the happiest days in your recent memory, the day you were offered a position outside of the individual contributor track, you find yourself with a million questions. You feel that you were tricked into signing something without reading the fine print.

That feeling you’re experiencing isn’t new, it’s just that you’ve all but forgotten it. It’s not knowing what you’re supposed to do. It’s being clueless. Because if you think years of writing software trained you to become a manager, research states the contrary. But it’s not the end of the world. Even though your company most likely doesn’t understand the need for formal management training, there is a plethora of information available to you that will make your job easier, and maybe even enjoyable.

When I became a manager I did what I typically do when faced with a challenge I know almost nothing about: I started reading. I’ve read a lot of books, some were good, a few of them were amazing. All of them shaped the way I do my job, and so I thought I would share them for other aspiring or active managers out there.

I’ve curated this list based on several factors:

• The books should cover a broad set of engineering management and leadership topics. It’s easy to find overlapping books. It is much harder to find a diversity of information when you’re very new to leadership.
• They should be written in different eras. The software industry is constantly evolving. It doesn’t make sense to only read about what was happening in the 1980s or 90s.
• Reading order matters a lot. Some books are more specialized than others. The information provided can be thought of as layers that stack on top of each other. If you’re inexperienced, you may start in the middle or the end, and that will basically ruin other books for you.
• Finally, I put a hard limit of 7, just because I think this list is enough to build a foundation layer on top of which you can continue reading and maybe even doing your own research further on.

But enough introduction, let’s see the list :)

Peopleware: Productive Projects and Teams, by Tom DeMarco & Tim Lister

This should be mandatory reading for everyone. Period. No, not just everyone in software, everyone working in a private company should read this book. It’s amazing to me how pretty much all of the problems that people deal with it on a daily basis have already been solved. In the 1980s. If you read just one book from this list, let it be this one.

High Output Management, by Andrew S. Grove

Soon after you make the switch from the individual contributor track to the leadership track you will ask yourself a basic question.

How do I measure my own success?

You used to be able to answer that easily. Now that you’re writing code less and less, and dealing with team dynamics and people problems, how will you or your boss measure your progress and success? This book provides a now universally accepted answer: you are measured through the success of the people reporting to you. That is to say, if your team is successful, then you’re successful. I’m over-simplifying of course but that was my biggest take away from this book.

There are more insightful bits of information such as a walk-through of a production pipeline, how to run meetings, or how to conduct one on ones. This is a classic book that everyone should read even if they’re not interested in leadership roles. It’s that good.

I will say though that this book was written a long time ago. The impression I got was that leaders from that age were more authoritative than what you see in companies these days. This is not a critique, it’s a fair warning. You may read a few chapters and conclude that there’s no way anyone could get away with doing that in a company. There’s a certain nuance to the leadership style described in this book and it is important to understand it.

Influence: Science and Practice, by Robert B. Cialdini

An engineering manager’s job is to ensure their team has everything it needs to succeed. This means managing the interaction between multiple groups of people towards an agreeable outcome.

If you’ve ever tried to convince a friend to move from WhatsApp to Telegram and failed, you’ve made an attempt at exerting influence. You’ll need to do that basically every day, and in my experience, this is a very hard skill to learn. It takes a lot of practice, and there’s really no sandbox mode in which you can fail and it’ll be OK. You will try to talk to someone at some point into doing something, and you will fail, and you or your team will suffer for it.

This book is the definitive guide on how to approach the problem scientifically. A lot of managers seem to think they don’t need to learn how to influence others, particularly their direct reports, as rank is the ultimate influencer. Thinking that will keep you from ever becoming a great leader, in my opinion. Yes, you will probably overrule someone at some point and it will feel terrific while you do it. But if that person ends up hating you for it, you’ve just lost their trust and you will see the consequences of that later on.

Rapid Development: Taming Wild Software Schedules, by Steve McConnell

This is another classic textbook that I wish everyone in software would read. If you’re currently in a company who’s agile and are struggling with unproductive meetings, poor quality code, team members that can’t get along with each other, or stakeholders who push you to leave the office late at night, you will find at least one solution within this book. It’s also a good leadership book as it describes, in what is probably my favorite chapter, a list of things you definitely should not do if you want to have a great team. I still refer to that chapter from time to time, it’s just really good and insightful.

Managing Humans, by Michael Lopp

I loved this book for its humor and insights into some of the biggest tech companies’ cultures. It doesn’t feel like a textbook compared to the others on this list, but that’s what makes it a great fit.

You need to understand that leaders are still human, they’re going to screw up, and the end result may be tragic or hilarious. Or both. That’s a very important lesson to learn, one that took me the longest time, to be honest.

It’s very easy to get caught up in theory while trying to learn how to be a leader. But reality often is so insane that no book can offer you the solution you need. You will end up in situations where you will do everything by the book, and people will still be unhappy. And that’s OK. The stories from Managing Humans will help you understand that.

The Manager’s Path, by Camille Fournier

What makes this book awesome is that it offers a clear and simple description of your responsibilities and goals at every step in the leadership ladder. Most companies don’t even have that information for their own leadership track.

It starts by describing what an entry-level leader should focus on, such as mentoring junior developers. It moves on to engineering managers, senior managers, and even covers what a VP of software should do. I personally have always wondered what a day in a VP’s shoes looks like, and if you have as well, this book is for you.

Beyond just taming your curiosity of what the upper echelons look like, I love this book because it is so realistic. There’s no utopian view of teams and processes here. It’s all ground in the experience of the author. That makes the information within highly applicable in your work environment.

The one minute manager, by Kenneth H. Blanchard

I initially didn’t want to read this after I found it, but I’m glad I changed my mind about it. It’s basically a short story about a manager who is very good at his job, particularly in one area.

I won’t spoil it for you. The information you get out of this story isn’t particularly innovative. There are other books that dive into its topic in more detail. But there’s something really satisfying about it that I can’t really explain. It’s like a GitHub gist that solves a problem in under 100 lines of code.

You can be dismissive of it — there’s no way it could be that simple, right? Or you can read through it carefully and appreciate its simplicity, knowing that it’s not a generalized solution, but still good enough that it’s worth having in your toolbox. It is entirely possible you’ll read this book and think I’m exaggerating, but hey, it’s my list ;)

Radical Candor, by Kim Scott

I can count to 7 just fine, but I really wanted to offer this book as sort of a special addition to my list. I wouldn’t say it’s mandatory reading. Once you’ve gone through all the books above, you should pick this up for a very striking alternative view.

Basically, Radical Candor is a framework on how to relate to people. It’s not really related to software development. You can apply this anywhere, with your friends, with your family, it’s frankly very abstract in that regard.

The author, Kim Scott, has worked both at Google and Apple. She recalls some of her experiences while working there. I found those chapters to be extremely enjoyable, but do take them with a grain of salt. Some of the more recent reports in the media directly contradict some stories from this book. This is why I’m hesitant to recommend it to everyone.

The framework itself makes sense but it’s so hard to actually put in practice. I know that’s not the author’s fault. I wish the world would work in the way she describes, but I don’t think it ever will. Nonetheless striving to achieve even 50% of Radical Candor will make you a better leader. If you have the stomach for 100% then I’d like to meet you in person.

Is that it?

This list is a solid foundation for newbie managers or people who are thinking of becoming team leads or managers. There is so much more to learn. I would’ve appreciated a simple and short list like this myself when I made the step towards leadership. Hopefully you do as well.

Books that every engineering manager should read was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Computer science fundamentals is not something you should avoid or ignore.

Simpler times

Let me back up a bit. In high school I was part of a class that was specialized in computer science and English — I’m Romanian, so foreign languages is something we need to get good at to succeed. The curricula was decent. We wrote code in Pascal, which wasn’t the best choice maybe compared to C or C++, but it wasn’t a hindrance in solving programming problems. I learned the imperative paradigm, sorting algorithms, data structures such as arrays, graphs, and trees, techniques such as backtracking and divide et impera, and more.

By the 12th grade, which is senior year in Romanian high school, I thought I had a good command of CS fundamentals. I enjoyed writing code, even though I was pretty bored of not being able to visualize output in any graphical way. This is what eventually drove me towards front-end development years later.

I never participated in olympiads or other competitive events. Somehow, even though I liked programming, I didn’t see the point of them. Thinking back I now realize this was a mistake, and it probably affected my career more than I’d care to admit.

I took an entrance exam and was admitted to the Academy of Economic Studies in Bucharest, majoring in computer science and economics. This particular bachelor’s degree helped me with knowledge regarding several programming languages such as C++, Java or C#, however in the area of algorithms and data structures, the curricula was pretty light. I would say it was on par with senior high-school year. Which basically for me meant that I couldn’t progress just by doing course work.

In my 2nd year of university I decided to get a part-time job as a software developer in test. I wasn’t really applying anything I had learned in school though (what a shocker, right?). I continued my career at a few startups, and I gradually forgot everything I ever knew about algorithms and data structures. My jobs didn’t really demand it. The tasks were always related to using frameworks, writing code without any performance constraints, or maintaining legacy systems. But I was growing as a developer. I was being promoted, praised in yearly reviews, and I got good at applying design patterns and writing clean, testable code.

Success

How exactly do you measure your success as a software developer? If you work for a company that produces software, and you’re constantly solving your tasks ahead of schedule, getting promoted up the individual contributor track, would you think you’re actually stagnating?

Yet most business software development is built in such a way that developers are interchangeable and the ramp up is cheap and fast. This is advantageous for companies, and enthusiastic for most developers, especially junior ones. You don’t need a CS degree to write code using frameworks such as Spring or Django. You just need to be able to read documentation, use a modern IDE, and get through some on the job training on how to write tests and contribute to the project.

I have never once had to think about the complexity of the code I was writing. Most systems I was working on did not have that much traffic, and the ones that did — they worked around it by throwing money at the problem via over-provisioned servers.

I stated that CS fundamentals is a topic you absolutely need to get good at. Let me explain why. There are limits to how far you can go career wise without ever learning seemingly boring stuff like what is a self balancing tree, or what it means for a sorting algorithm to be stable. I think the fact that you can progress so far and so quickly in software without this knowledge is a big problem. It can lure you into a sense of false security which will hit you painfully at some point.

For me that point was when I started working at Hootsuite. The nature of the problems I faced immediately after I was hired were exponentially more difficult than anything I’ve ever seen before. Performance was at the heart of everything we had to do. And this is where algorithms and data structures become increasingly relevant. You can certainly take a matrix sized 50x1000 and loop through all of it once per each item you’re searching for. This is made insanely easy by using libraries such as Lodash or Underscore. You may even get away with it in most cases. But if you’re dealing with a large piece of software, with lots of things happening all at once either on screen or behind the scenes, in your back-end code, efficiency is mandatory. Caring about it will also distinguish you from other developers.

Working in a performance oriented team is extremely challenging, but it can also be the most rewarding experience in your career. I figured that out eventually, but I spent years in companies that never pushed me hard enough to become a better software developer. I spent time reading and applying design and testability patterns, which certainly helped. But the reality is you can have a beautifully architected system that just isn’t scalable. And you can’t Google how to get there. You can’t Stack Overflow your way to writing efficient code.

After I was hired I decided that I needed to freshen up my CS fundamentals fast. So I devised a plan.

The Goal

I’m still a bit old fashioned when it comes to studying material, so I bought “Algorithms Fourth Edition”, by Sedgewick & Wayne. I wish I had this book when I was still in school. It is very different than any textbook I’ve ever used. It doesn’t just force feed you algorithms, it offers so much context around why we even have algorithms, or how to measure them. It also presents a real world problem before presenting the solutions, which is contrary to pretty much how my entire education system was (and still is) designed. By structuring the chapters like this I finally understood the importance of starting with a basic algorithm, which may not be very good, and evolving it until you get to an optimal solution. This is also how major companies run their technical interviews.

I felt pretty good as I progressed through the chapters, there were a lot of things that I had previously read but forgot, and there were certain algorithms which I had never even heard about. It was starting to make sense, and I was happy with my progress.

Then I decided that I needed some coding practice. It’s one thing to read about a tree, but quite a different one to be able to solve a programming problem involving one. I discovered leetcode.com, a competitive programming platform which is free to join (with an optional premium tier) and offers hundreds of problems.

I decided on the spot that I had to set a goal for myself, otherwise this would just end up like my list of GitHub repositories. Exciting at first, but ultimately abandoned in my endless to-do list of ideas and projects. I thought I had to make the goal very easy to measure, and ambitious enough such that it would force me to work hard enough to achieve it.

So I settled on solving 100 Leetcode problems by mid 2019. This number felt high enough that I’d need to work for it, but still low enough such that I didn’t have to go out of my way and pull all-nighters. The only time I could work on this was from home, and that pretty much means just the weekends.

Tracking

Leetcode makes it trivial to measure your progress with a pie chart of completed versus total number of problems. But the profile page is a bit hidden, and you need an account to be able to even access someone else’s stats. This was mildly annoying, but the second problem I found was much worse. Your solutions in the platform are not easily searchable after the fact. You need to either have the code in your browser’s local storage, or go to the submissions page of each problem and find it. As I was still struggling with problems, I needed a fast way to go back to a previously solved solution for help, and Leetcode wasn’t making this easy.

So I decided I was going to host all of my solutions in a GitHub repository. I figured it was OK to do that since I would only be publishing the accepted solutions source code, not the problem description, which rightfully belongs to Leetcode under a license.

The repository is located at https://github.com/ovidiubute/leetcode-js

All of the solutions are located in a single directory, and I used a simple naming scheme to track problem IDs and titles. This maintains a certain tidiness and it also makes it easy to search for solutions directly in GitHub.

I used JavaScript as my language. This could be an article topic on its own, as there are many caveats to using JS for this type of work. But it’s been too long since I’ve written C or Java and I write code in TypeScript every day at work, so it seemed like a logical choice. The main drawback is you have none of the advanced data structures such as HashSets, Heaps, or Queues. When faced with a problem that requires them you’re pretty much on your own and have to re-implement them.

I also implemented a badge on the repository’s Readme that tracks progress as a percentage. This was a fun little side project that meant learning how the shields.io endpoint system worked. Whenever I contribute a solution, I run a Node.js program that updates a JSON file in my repo. This is then accessed by shields.io and their systems read the badge, text, colors, and percentage, rendering an SVG similar to the one below.

Results

I hit my milestone way before my target deadline. This was both good and bad for me, as on one hand, I was completely stocked that I was able to solve 100 problems given my years of neglecting algorithms and data structures. But on the other hand, I had aimed way too low, which felt a bit disappointing.

Setting a tangible goal forced me to take this task seriously. Measuring it made it easy and also comforting as I could see my progress from one week to another. However I made two mistakes when defining the goal. I didn’t think to split the goal by difficulty of the problems. Leetcode offers problems in three difficulties, and I gamed my own system by solving a lot more easy problems than medium, or difficult. Granted, it’s ironic for me to say that given that when I started a few months ago, the easy level felt impossible. I had forgotten so much from school that it felt like my goal was a cruel joke I had made myself suffer through.

Gradually it got better, though. Had I not been so dismissive of my own skills, I would’ve set a harder goal. Something like solve 80/30/15 problems, split by difficulty. I also should’ve pushed myself for a tighter deadline.

Did it matter that I spent this time remembering things that I only rarely use in my day to day job? Well, from what I can tell, I’m much more attuned to how my code performs now. Writing efficient code is something you don’t just get good at by solving a few coding tasks, but the difference between my mindset now and how I used to think six months ago is significant.

I also appreciated the exercise. Coding is not just thinking about ways of solving problems. There’s a mechanical element to it. By writing a lot of code your muscle memory improves, leading to faster typing of repetitive patterns. You shouldn’t have to think about how to traverse the diagonal of a matrix, or how to remove duplicates from an array.

Recap

So I went from studying computer science in high school, to sort of continuing to study it in university, to rarely applying what I had learned on the job, to a new job demanding I get good at it again. A typical week-end day for me looks like this:

But I absolutely enjoy working on it! I got into programming because of the exhilarating feeling of asking a computer to do something. At first it was printing text on the screen. Then answering an HTTP request. Then animating a sprite on a mobile phone. The feeling is still there, but it took me a long time to realize that everything is built on top of the same foundation. Languages and frameworks are transient. They change, they die, they get replaced. As a junior developer I was convinced that keeping up with these changes was a sure way to achieve success. I worked for many companies that rewarded this behavior. I had never worked for one that rewarded being good at the foundation layer. Now I do and I need to catch up on some wasted time.

I’m going to go into the why and how of migrating a large JavaScript code base to TypeScript. Our team has concluded a fifteen month long journey of revamping our front-end stack. To up the difficulty, we had to did this in parallel with delivering new features to our customers. At the end I will also talk about whether it was worth the effort or not, and how it affected our development.

Start with “why?”

Hootsuite Analytics is a single page app built from the ground up in JavaScript. We rely on the React library, of which we were very early adopters. At a very high level, our app consumes data from our set of backend APIs. It then transforms that data into several types of visualisations. We render rich tables that display social media posts, charts, graphs, maps, and more.

Over time our app has grown quite a bit, and is now sitting somewhere at 150 thousand lines of code. At Hootsuite we invest a lot in the technical aspects of our products. We do that by always assessing whether what we are doing is sound from a technical point of view. Any major project must start from a problem definition, so let’s talk about what were our technical challenges.

JavaScript is a difficult language to model data transformations in. It is a dynamic language, and, without going too much into the specifics of what that means, it requires developers to make a trade-off. They don’t need to specify what data looks like before hand, which makes initial development very fast. The flip side is that, as a project grows both in lines of code and number of contributors, it becomes exponentially more difficult to reason about the data flow throughout the various layers of the application.

This problem is somewhat compounded by using React. Since it is built on functional programming principles such as immutability and composition over inheritance, it encourages developers to treat components as small, reusable functions. In a medium or large application it’s typical to have hundreds, thousands (or even tens of thousands) of components. Data can flow through tens of components at a time.

Imagine having to read through a tree of a dozen React components with no information on what the data looks like at each step. This was what the world looked like in 2015 to us. Now, as astute readers will point out, React offers a feature that helps with this: PropTypes. But they are optional and quite difficult to maintain. We didn’t use them from the beginning, we adopted them a year later and started adding them to new components. In our experience they did not deliver enough information to balance the maintenance effort required. There are also more practical concerns: most IDEs do not attempt to parse PropTypes to offer hints, you need tools to enforce their correctness, and it is a limited type system, not robust enough for our needs.

Another problem we experienced was that, due to a lack of information about the data flow, it was difficult to perform basic refactoring. Moving files around, splitting large components into smaller ones, or renaming files — these operations were both time consuming and risky. Our team embraced unit-testing since the very beginning, so we could not crash our app by moving files around. But it was still time consuming.

This led to an interesting realisation: developers rarely refactor code unless it is cheap and safe to do so. The reality was that our code base was in a dire technical debt state. Developers were wary of making major changes for fear of breaking functionality or spending too much time on what they initially thought to be basic tasks.

The lack of code completion and contextual hints was the third, and most annoying problem of all. Myself and a few members of our team come from a back-end development background, working with strongly typed languages such as Java or C++. I still remember the first time I wrote JavaScript code in an IDE. As I was working, all I could think of was…

Wow, writing code without any IDE suggestions is hard!

You do get used to it after a while, but in my opinion, you will never be quite as productive as in typed languages. There is too much going on at any given moment within a JavaScript program. There are too many possibilities, data can have any shape and can mutate at any time without warning.

So to sum it up, we were facing three major challenges:

• Difficulty in following the data flow
• Expensive refactoring
• Lack of contextual information in IDEs

We decided to start the search for a solution, and we realised we had to go outside the bounds of the JavaScript ecosystem to find one. We took a look at what the open-source community offered as options for front-end development. It is an amazing time to be building web apps as there are many, many choices beyond JavaScript.

We did have a very critical restriction. Hootsuite is a business, millions of customers across the world depend on us, so we couldn’t stop development while we migrated our code to another language. The migration had to be gradual. We would write new code in our new language, while slowly rewriting older code, without interfering with the product roadmap we had to ship. So we made a shortlist of options, and debated them one by one.

One of the first languages we took a look at was Elm. Bogdan Zaharia, a member of our team, is a huge proponent of functional programming in its purest form. He was the one that introduced this language to our team. Elm was inspired by Haskell, and offers a robust, typed alternative to JavaScript. While attractive, we couldn’t make the transition to it easily. We could not find a simple way to gradually adopt Elm into our code base. Additionally, it’s not very newbie friendly. It requires developers to understand some non-trivial concepts from the functional programming world. We also had to consider how easy it would be to onboard new developers in our team to Elm. After weighing in all these drawbacks, we decided to keep looking.

Other options that we analysed:

• Dart: this language is becoming popular again due to Google investing in Fuchsia. Dart is its de-facto UI tech stack. The lack of a transparent roadmap and uncertain future meant a very clear no go.
• PureScript: this is Haskell for front-end development. Same arguments as using Elm. To be honest, it has an even steeper learning curve than Elm.

We had two candidates left on our list: Flow and TypeScript.

It was not easy to choose between these two given their similarities. We invested some time in research spikes to see first hand what development looked like in both cases. What we found was that Flow was more difficult to set up than TypeScript, and that the developer experience felt sluggish. This has improved though in the last year, so if we were to analyse them again today, this wouldn’t have made such a big difference.

Both type systems are solid, yet very different. TypeScript uses a structural type system. Flow’s system is both structural and nominal. The difference is key to how they integrate with the greater JavaScript ecosystem. I will summarise what that means, but if you’re interested, this article goes into much more depth. A nominal type system implies that two types, Foo and Bar, are never equal, regardless of their definitions. TypeScript, using only the structural alternative, doesn’t care about what the types are called. It analyses their structure and determines whether it should act like they are equal. In practice this means writing code is less demanding on you. You can easily reuse types and interfaces and you can even define them inline without naming them.

We also looked at the communities around these two projects. Flow is a language that, at least a year ago when we ran this analysis, was being driven by Facebook in a very closed manner. Development was never transparent, there was no public roadmap, and very few people outside of Facebook were contributing to the project. TypeScript, in contrast, embraced open-source development since moving to GitHub a few years ago. They keep an up-to-date roadmap, accept outside contributions, and generally keep a very close relationship to the community. Anders Hejlsberg, a Microsoft fellow and chief architect, speaks at conferences (such as TSConf) throughout the year, keeping everyone in the loop on what features are coming next and how the project is performing.

So as you might have guessed, we chose to go with TypeScript. This was a pretty long intro on why we did it, but it serves as a good template for other teams when deciding to change tech stacks. I’ve seen too many teams do tech switches by starting with the “how”, rather than the “why”. Rather than stating that your team wants to switch over to another language (or stack), start by understanding your problems.

1. What are our current difficulties?
2. How do we prioritise them?
3. Are they solvable within the current stack?

You should always go through these steps so that you may reach the best possible solution.

Continue with “how?”

At this point we had reached a consensus that we wanted to begin rewriting our code base in TypeScript. The first step we took was to ensure that we could actually write TypeScript code.

We built Hootsuite Analytics on top of modern software practices. We have a continuous integration pipeline that helps us deliver code to production only after changesets pass several checks:

• Linting
• Formatting (using Prettier)
• Unit-tests
• Code coverage
• Acceptance tests

We have three different environments: development, staging, and, of course, production. When thinking about adding TypeScript, we had to make sure it didn’t interfere with the pipeline. And we also had to make it seamless for developers.

I won’t go too much into the specific technical details of how we integrated TypeScript into our code base. There are far too many excellent articles and tutorials out there that describe the process better than I can, and I suggest you check them out:

• https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html
• https://medium.com/pleo/migrating-a-babel-project-to-typescript-af6cd0b451f4
• https://medium.com/@clayallsopp/incrementally-migrating-javascript-to-typescript-565020e49c88

I will, however, describe our philosophy, our pain points, and what we’ve learned along the way.

One of the most important decisions we made at the beginning was to enforce strict mode. Strict mode is a combination of several compiler flags that, when turned on, perform extra type safety checks on your code. I would recommend any team that starts a TypeScript project to use strict mode from the get-go. Moving code written in non-strict mode over to strict mode is actually really difficult, and you’ll save yourself time in the long term by enabling this mode early.

One of the potential downsides of strict mode is that you can no longer import JavaScript code unless it provides a TypeScript declaration file. If you’re not familiar with that term, it’s like a C/C++ header. You need to write types for your data structures, classes, methods, and functions. A lot of projects include declaration files written by the maintainers. However we depended on a few that did not.

To solve this issue the community has done an amazing job with the DefinitelyTyped repository, filling in for authors who have neither the time, interest, or expertise to write and maintain their own declaration files. We didn’t have any problems finding declarations for all of our dependencies after consulting it. Unfortunately we did run into a few problems upgrading them down the line. For reasons better explained in this GitHub issue, it can be challenging to find the right combination of versions. With projects such as Redux (which we use and love), there’s an entire ecosystem of dependent projects, each with their own community driven declaration files. You usually need to upgrade all of them at once so as you can imagine, it can get frustrating.

To make matters worse, our app depended on a few in-house written and hosted packages, and they were all JavaScript. As a result importing them would break under strict mode, so we had a new problem on our hands. We had two options: either ignore the compiler errors (using @ts-ignore), or write the declaration files ourselves.

To not get stuck on this particular problem we ignored the import errors. We made a commitment to go back and write the declaration files (which we did, in time). I would recommend this approach to other teams as well, since if you’re just getting started with TypeScript, it’s a strain to write declaration files. Depending on how dynamic your APIs are, it could require intricate knowledge of the type system to finish. In the early adoption days when you’re getting the hang of things, you don’t want to be spread too thin.

Another challenge we had was linting. During our research we found two ways of linting TypeScript code: TSlint, a tool developed in-house at Palantir and subsequently open-sourced, and ESlint, the de-facto linting tool for JavaScript, together with typescript-eslint-parser.

We were already using ESLint in our pipeline, so our solution was to adopt a dual setup of ESlint to check JavaScript code, and TSlint for the new code. This felt right at the time since we thought about using the best tools for the job, but it brought a lot of downsides. We had to maintain two linting configuration files, two lists of rules, we had more dependencies we needed to keep track of, and we had two different linting outputs whenever there were errors.

Fast forward a couple of months we consolidated on ESlint for checking both JavaScript and TypeScript code. We accepted that, even though we lost some more advanced TSlint specific rules, it was not worth the effort of keeping both tools in our pipeline.

With tooling solved, we had to decide how to approach the code migration. Like I mentioned earlier, there would be no huge one time rewrite, we had to continue supporting our product roadmap, which meant delivering features and maintaining the application. We ended up with two rules that would guide our work.

• New code must always be written in TypeScript. No exceptions.
• The code base will be treated as a copy-on-write data structure. If your task requires you to change JavaScript code, you need to rewrite it.

As you can imagine, this didn’t always go smoothly. While writing new code was fun in TypeScript, importing legacy code remained an issue. Our first few pull requests were unusually large, and thus difficult to peer review. We tried to get to the bottom of the problem during our weekly JavaScript Guild meetings. It turned out that often developers needed to go into the legacy modules and fix problems that were just then being uncovered by the compiler. So pull requests that should’ve included one or two files were now hundreds or even thousands of lines in size because of our second migration rule.

We still wanted to uphold the vision, so we decided to take a look at the major offenders that were causing the large changesets. These were mostly older core React components or utility functions. These modules had been reused across the entire project, so changes made to them cascaded across the entire codebase. Rather than spend time upfront in rewriting them, which would have potentially caused delays in our product roadmap, we wrote declaration files for them. This helped a lot in reducing the size of subsequent pull requests. We delayed rewriting these modules until we were further along with the migration.

If your team does this, word of warning — you are, in effect, adding technical debt. You will need to maintain these files, which is not simple. It is very easy to change JavaScript code without updating the corresponding declaration files. Your app will compile but crash and burn at runtime. In practice, we very rarely had this problem, due to our decent unit-test coverage. Try not to keep the declaration files forever, though, and commit to rewrite your code at some point.

Of course we also shipped some bugs in production during rewrites. The amazing value in type systems is that you can catch so many bugs at compile time instead of runtime. That was never the case for us before the migration, though, so we had a lot of lingering bugs waiting for the right conditions to manifest themselves.

Was it worth it?

The best measure of success that we have so far is the number of production deployments. We built our pipeline in such a way that any merged pull requests trigger a production release. This means we push new releases out to customers on a daily basis. Our hunch was that, due to the uncertainty that governed our code base before the migration, we never deployed as often as we could have. And we were right.

The number of times we release to production has doubled compared to 2017.

It’s never easy to attribute statistical success, so I am going to eliminate the usual suspects that may have influenced this chart.

The number of front-end developers on our team has largely remained constant. So while there is some correlation between headcount and production pushes, it is not enough to explain the trend.

We did not put Analytics as a product on pause, our roadmap has been a constant flux of features, so that’s also out of the question. There are some seasonality influences. We enjoy a peaceful code freeze during Christmas holidays each year. During that time we cannot push any code to production. This explains the low activity at the end of each year.

We are still early in analysing the impact this migration has had on our code base. Quantitative data suggests we are shipping more often than ever before. Qualitative information is also very valuable. Our developers love the contextual information that the types offer (especially now that everyone in the team uses VSCode or WebStorm). They are writing less tests because bugs are now uncovered during compilation. They are generally happier about the quality of their code. On-boarding new developers into the project, which historically has been very difficult, is now faster. We plan to do another check-up in six months and see if these initial results still hold up.

You would think that this migration affected our product roadmap, due to all the refactoring work. That was not the case for us. We managed to deliver all our projects on time. The caveat of this is that at Hootsuite we never work under the pressure of fixed, non-negotiable deadlines. I can also attest to the fact that certain features we delivered would have taken much longer had we needed to work in JavaScript. Parts of our code base are approaching four years of age. New features around them would have certainly driven up estimations.

In closing

This migration would not have been possible without the passion, grit, attention to detail, and hard work by our developers in Hootsuite’s Bucharest office. I’d like to thank Bogdan Zaharia, Flavius Tîrnăcop, Gabriel Ilie, Sergiu Buciuc, and Sînziana Nicolae for keeping the TypeScript dream alive, and in general for an amazing past year. I’m happy and proud to be working on a team that can get motivated when faced with a project like this. Looking forward to our next achievements.

Have you ever migrated a code base to another language? Share your experience in the comments, and let us know if you found this article useful.

Thoughts on migrating to TypeScript was originally published in Hootsuite Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learning to write code in a new programming language is similar to learning a foreign language.

You may have been driven to study it by a tangible need such as moving to a different country, or creating new business connections. Or you may simply have decided it’s a challenge worth taking on. Regardless, it felt intimidating at first. Maybe you could already understand some words because they were similar to your maiden language. Maybe you could even read a newspaper and get the gist of it. But writing and speaking felt very difficult when you first started out.

The advantage programming languages have over foreign ones is that they have comparatively smaller grammars. An experienced developer can pick up all of the syntax rules within days. It’s a great feeling to be able to read and write code within a week of starting, and it may even seem productive, at first.

Don’t be fooled, though, because it’s not really as simple as I’m making it out to be. Because knowing syntax and being able to get a program to run is not really at the same level as being able to read and write in a foreign language. Imagine not knowing any Spanish but still being able to read a restaurant menu and ordering something. Maybe you don’t recognize the subtleties needed to have a conversation with a native speaker, yet you can perform trivial tasks with little effort. In the same vein, you’re sure to be able to read and understand source code, up to a point, in an unknown language, especially if it’s similar to something you’re already familiar with. As an example, if a developer has experience in C++, he/she will feel right at home with any of the languages that have a similar syntax such as Java, Rust, C#, or PHP.

What’s most important in a programming language is not syntax, though. It’s actually finding its utility, knowing the type of problems that can be solved with it, and following the design patterns that it enforces. Learning to write idiomatic code should be your ultimate goal, and this is what this article is about: understanding the need to track your journey towards mastery.

As a developer, you absolutely should invest time in learning new programming languages. It doesn’t matter if you‘re at a junior, mid, or senior level, or if you’re currently writing code full time in a particular tech and will never switch to anything else (even though this is highly unlikely). The experience alone will make you a better coder, because you will find different ways to tackle problems and you will be able to import patterns from other languages into the one you’re already using (most of the time, and I’m thinking functional vs imperative).

To be able to reach a certain level of proficiency, you should define for yourself a set of metrics. Tangible goals towards which you can track your progress. If you don’t, you may end up in a situation where you’re unable to ascertain if you’re ready to start a project using a particular technology stack.

I’ve written code at least once in over a dozen languages. By no means does this entail that I am comfortable with all of them. I’ve already set my own metrics by which I can judge my ability. Allow me to list them and explain my motivations for each of them.

Excellent command of syntax

You should not be surprised why your program does not compile if the error is purely syntactic, nor should you spend any significant time trying to solve it. A good metric for this is whether you’re able to write code without an IDE and it will pass the compilation or interpretation stage without syntax errors. I’m generally an advocate for using an IDE because we, as developers, usually have more work to do than we can get through in a usual day, so any productivity boost should be welcomed, not excluded for any subjective reasons. However if you always use an IDE you may miss out on learning how to correctly write code by yourself. An IDE also may have shortcuts for repetitive and boring code (commonly named “boilerplate”) and you may be tempted to use them simply because they’re available.

I need to make a note here; languages evolve over time. If you check out the latest standard of JavaScript, ECMAScript 6, and the first edition ever published, you will notice there are many, many changes. This begs the question of should you feel that because you’ve mastered the syntax of a language at some point in time, but you haven’t worked with it at all for months or years, does that mean you’re no longer knowledgeable? I’m going to answer no, and here’s why.

Everything changes in software development. The landscape is shifting constantly, new languages are added every year, and the sector is probably one of the most dynamic and competitive in the world. If you have invested time to learn a programming language, and consider yourself productive, no amount of time can cancel that out. Imagine you’ve spent working 5 or 6 years in C++. You can’t even remember the standard that was in place at that time. It doesn’t really matter. You have a huge advantage over everyone starting out with C++ 17 (the latest revision of the standard at the time I’m writing this), because you’ve taken the time to master it at one point, and you will be able to approach the design changes with a lot more confidence than a novice. Myself, I wrote a lot of PHP years ago, starting out with version 4 (for the nostalgic among you, remember writing almost OOP code?), then moved on to 5. Version 6 does not exist, for reasons that would take too much time to explain. Now, PHP is at version 7. Because I haven’t kept up with it, I obviously have no idea what has changed in the language, from a syntactic point of view (I did hear that lambdas were added, which is awesome). One thing is certain, though, I’m confident in my ability to pick up PHP 7 if I had to, because I invested a lot of time to work with it in the past.

Understanding its strengths and weaknesses

This requirement is very important because it enables you to use the right tool for the job. You will have to know and accept the limitations of the language and not try and coerce it into doing something that’s not idiomatic. Think of trying to write a triple A game engine in Pascal, or a CRUD backend in Bash. Think that’s too contrived? How about writing a library that enables static type annotations in Python, a language that is designed to be dynamically typed, and is one of its strongest features. I actually wrote this while working at a startup, and it took me some time to understand why it was a terrible idea.

It helps to know that some languages are so called “general purpose”, which means they can be depended on to solve problems across all of the domains within computing. The prime examples are C and C++. Other languages are more niched, and they wouldn’t make good candidates for solving certain problems, such as Swift or R. There is however a lot of power in specialization.

Good knowledge of the standard library

I cannot stress this enough. You will never truly master a language unless you learn how to use its standard APIs.

Be mindful of the fact that you will not be able to fully understand and work with all of them, though. Some languages such as Objective-C come with a frankly huge set of APIs associated with the iOS operating system (even though you can write Objective-C code anywhere, it is most often associated with iOS and macOS development).

Try not to focus too much on memorizing functions and packages though, this does not scale well at all as you progress through your career. I remember obsessively reading the Java API spec years ago trying to learn as many APIs as I could by heart in case I’ll ever use them. Guess what? I only used a handful on a regular basis.

There are also some languages, such as JavaScript, that come with a fairly limited standard library. Historically this has been the reason why so many third-party libraries stepped in to fill the gaps, leading to an incredibly fragmented and fragile ecosystem. Consider the fact that most JavaScript developers started out by learning jQuery, a library that, at one point, had become so pervasive, you could be forgiven for thinking that it was a programming language in and of itself. This doesn’t mean you get a pass, though. Regardless of how badly written or unintuitive these APIs may be, they are the building blocks with which every library and framework is built, and ignoring them will relegate you to a downstream user of them. Besides that, the limited APIs may be a temporary situation. Java’s Collections API, for example, has received numerous updates in its 8th version, and the Calendar API, once one of the most hated aspects of writing date/time focused code, has also been massively improved (with the help of a third-party lib called Joda Time).

Once you’ve mastered this requirement you will be able to author your own libraries to solve very specific problems that you encounter. Don’t take this into consideration, though, when evaluating your skills. You don’t need to be the author and maintainer of a popular library or framework to be able to say you’re proficient. The reverse is also true.

So these are my preconditions on how to evaluate programming language expertise. You’re probably wondering if I follow my own advice. Am I honest about my own skills? And you may also be thinking whether it pays off to be this honest, and what happens if your resume looks less impressive if you follow this methodology and starting removing certain skills?

I cannot stress this enough: you need to be honest with yourself if you want to evolve as a software developer. It’s going to be a long journey until you learn enough to be proficient, there are no short-cuts. You need to treat your career as you would a platform with millions of users: it needs to be monitored carefully, constantly, and with a very objective attitude towards performance. This entails having tangible metrics that you can observe daily to track your progress. If you decide to start learning a programming language, no matter if it’s low-level, high-level, imperative or functional, take time off to evaluate how you’re doing. Ask yourself these three questions:

• Can you read and write a program without compile errors and without the help of an IDE?
• Are you aware of the pros and cons of this particular language?
• Do you have a firm grasp over its standard APIs?

As for myself, following the aforementioned conditions, I’m knowledgeable (or have been in the past) in four languages:

• PHP, which was my entry in the world of web development; as I said I’m no longer developing any software using it
• Java, judging by the years I’ve worked as a backend developer; no longer using it, I’ve switched to JVM hosted languages because they tend to be functional
• Python, which is still my go-to language for small projects
• JavaScript, the language in which I’m currently most involved in

I’m hopeful I’ll be able to add Elm to that list by the end of this year (still a long way to go), and maybe Clojure (I’ve worked with it before, but not enough to feel proficient). I’ve chosen them because they’re extremely different from what I’m familiar with. Elm is a purely functional language similar and written in Haskell, and Clojure is a Lisp. Even though proficiency is something that I won’t reach soon, the journey there will be worth it, because the architecture of apps made possible by these technologies is vastly different from the ones I’m used to working with in imperative languages.

I would advise you to do the same when picking what to invest your time in. If you love C++, I wouldn’t recommend choosing D as your next language. Not because D isn’t any good, it’s objectively very well designed, but you won’t learn any new patterns, and you won’t learn new ways to solve problems. You’ll write more efficient code, but it will look and feel very similar to what you’ve been writing all your life. Try to push yourself outside your comfort zone.

Let me know in the feedback section how your experience with learning programming languages has been so far.

My first reaction upon hearing this was of dismissal. Later on it got me thinking as to how I could convincingly present the advantages of testing. Because the usual arguments of “it’s the right thing to do”, or “you can’t scale a project without tests” can actually be countered pretty easily. We now live in an era of micro-frameworks, IDEs with integrated linters, and extremely short feedback loops provided by hot reloading technologies. It’s getting easier and easier to prove to someone that your code works even in the absence of unit or integration tests.

Let’s say you lend a friend a $100 bill, and at the end of the day, he reimburses you with ten $10 bills. Ask yourself this: do you count the bills before putting them back in your wallet? He is, after all, your friend, you implicitly trust him. But could he have made a mistake and given you nine bills instead of ten? Maybe eleven?

Suppose you answered yes, now consider the following: does counting the money make you distrustful of your friend? Do you believe that, even if he is your friend, it is your responsibility to protect yourself, and your money, from his mistakes, even if you don’t recall him ever making one?

If you don’t count them right then and there, when the transfer is made, do you count them later and get back to him if you find he’s made an error? What if it’s two days later and your friend no longer remembers what happened? What if it’s two years later and he’s already left the country?

These are questions that get asked daily across organizations of all sizes. They are particularly harder to answer in software companies, though, and that’s because of a little thing called bureaucracy. Few things anger us, developers, more than bureaucracy. It’s why we pay everything online, why we don’t understand the long queues at the Post Office, or the people refusing to exchange their printed meal tickets with meal cards. It’s an established cultural trait, one that has allowed our economic sector to be so innovative in the past thirty years.

There is, however, one drawback, and it should be apparent to us all: without oversight and paper trails, software can be easily mutated, redesigned, rewritten, changed beyond recognition. But what about the people actually working on the product? How do they keep up with the ever changing landscape? This is a subject that everyone gets asked about during technical interviews: “Do you document your code? How do you go about it?”, “What is a comment block?”, “How do you generate documentation from code?”, “How do you keep your documentation up to date?”.

That last question resonates with me a lot. After working in several companies of different profiles, ranging from telecom, social networking, to mobile gaming, I can say without a shadow of a doubt that trying to write documentation, and keeping it up to date, is humanly impossible.

Maintaining a test suite is the only infallible method of tracking and understanding the shifting complexities of a software product. Anything else is not worth investing in. This is the real reason that we write tests. It’s not that we don’t trust each other, it’s not because we believe everyone else is stupid and doesn’t warrant our trust, it’s simply because human memory is a fragile and finite resource. You should not have to memorize source code in the eventuality that someone reports a bug. You should not have to track the changes made by a colleague just in case a problem pops up two days after release.

If you’ve ever asked yourself what’s the point of testing your code, simply step back and imagine yourself in a few years time. Is it reasonable to think you’ll still remember the source code you’ve written, if any one of your users (code without users other than yourself is not the type of project that I’m talking about) reports a problem? Would you be comfortable handing over the project to someone else? How much time would he have to spend to understand the code at the same level as you?

It may take you a minute or so to prove to someone that your product still works today, but could you still do it in two or three years time? If the answer’s no, it may be time to invest in a test suite.

I’d like to spend some time analysing the state of a very powerful, but somehow little known, at least outside of sysops/devops circles, solution to monitor your production environment.

Zabbix, according to the Wikipedia entry, started as an internal project around the year 1998. Three years later, it was released under the GPL license to the world, but took an additional three more years to reach a milestone 1.0 release, in 2004.

The project has now been going for almost 18 years, which is amazing considering the typical lifespan of most open source projects. Development seems to be split between two branches, an LTS, bearing the 2.x version template, and a new 3.0 branch which, at the time of this article, is in beta.

Why is it then, that so few developers are familiar with Zabbix as a product? 1998 is the year Google was founded, after all. There aren’t really many examples of open source products founded during the 90’s that are still alive and kicking.

Well, I’ll be frank. If you are a sysadmin, Zabbix is an awesome tool. The distributed architecture of agents deployed on host machines, the templating, the frankly unlimited number of servers it can manage, the alerts, it’s all a great improvement over the somewhat ageing Nagios.

But if you’re a developer, and you’ve successfully deployed your backend app somewhere (managed or cloud), you should not be thinking about Zabbix, not in the year 2016. There are so many competitors these days that outdo Zabbix in the application monitoring space, it’s frankly absurd how some of Zabbix’s issues have not been addressed in almost 18 years.

Allow me to just list some of my biggest grievances with Zabbix.

No dynamic items.

Honestly, you don’t fully appreciate this until you use something like Graphite. No dynamic items means, before you can see your data plotted on a graph, actually scratch that, before you can add your data to the Zabbix database, you need to carefully, meticulously, and painstakingly add every single item definition in your application to Zabbix’s configuration.

So let’s just assume you’re running a REST based application. You have something like 20 endpoints, and you’d like to know how are these endpoints performing. So you add an atomic counter in every controller that just increments on each hit. Obviously, that won’t get you too far, so you also add a Histogram to each controller that saves the distribution of response time to the clients. Let’s suppose you’re running an app that needs to respond very quickly to requests (such as a Trading or Ad related middleware app). You’re going to set the distribution to something like this:

• 0..50 milliseconds
• 50..75 ms
• 75..100 ms
• 100..125 ms
• 125..150 ms
• 150..300 ms
• 300..500 ms
• 500..750 ms
• 750..1000 ms
• 1000..1500 ms
• 1500..Infinity ms

Seems like a reasonable setup. We can graph how many hits we have per endpoint, and how quickly our backend is responding to clients.

But can you guess how many Zabbix items we have to add to completely monitor our app? Well, one hit counter per controller plus eleven histogram related items per controller gives us a grand total of two hundred and forty items. And this is still a very small scale app. Remember we’re not really monitoring anything inside the controllers, just how fast they respond and how are they doing so. You’ll obviously need a lot more items to get a sense of how your app is doing.

But who’s going to add 240 items manually into what is obviously my second biggest grievance with Zabbix (its interface)? Nobody wants to do it, so either you trick the new guy into doing manual work for a day or two, or you do what everybody else using Zabbix does: you write a script to add the items for you.

So wait, let’s back up a bit. You’re writing this super cool backend app with all the latest tech, maybe you’re in a startup and one of the tasks for your next sprint reads:

Find a way to automate adding Zabbix items (5 story points)

Obviously, if you have worked with Zabbix before you know that an item is really more complex than I make it out to be in this article. And I’ll be fair, I understand why items can’t just be duck typed in like Graphite, StatsD, or pretty much any project at this stage. But is it annoying to have to configure them? Yes. It most definitely is.

How does any other backend manage this problem? Simple. By offering no configuration whatsoever. You want to add a metric to OpenTSDB? Sure, just send it. Graphite? No problem. The caveat is Zabbix’s items are more advanced from an operational standpoint. But like I said, if you’re a developer, you don’t care.

The GUI

Where do I begin with the interface? It really does seem that Zabbix’s GUI was designed for sysadmins to monitor the iowait and open sockets of Apache, not for developers to graph their JMX counters.

It’s just so tedious to do anything. That’s all I can say. The interface is at least 10 years past its prime, and if you’ve ever looked at dashboards such as Kibana, you’d be forgiven for mistaking Zabbix for a dead project.

The graphs

I refuse to criticize an image library that is about as old as the Internet. And yes I’m talking about libgd. Let’s just say that the Internet has evolved, and websites these days tend to have a wow factor them. Zabbix’s graphs have a ‘meh’ factor to them, and what I mean is that they are so bland and so unattractive to look at, you will not want them on that big screen next to the fancy Kibana screen that other team has been working on.

Conclusion

Enjoy Zabbix, if you’re a sysadmin, that is. For us developers, we’d very much like a bit more flexibility and visual appeal to our monitoring.

“What is clean code?”

The question always struck me as audacious. It’s like asking a painter to explain how to paint properly. But hold on, a painter works alone, and the finished product does not have to conform to a rigid specification. A painter doesn’t have deadlines either, at least, I’ve never heard of any. So that comparison doesn’t work at all. Hmm. How about asking a bridge builder? He’s part of a team, and the project’s deliverable is met with extraordinary technical scrutiny. I wonder what he would answer when asked:

“How do you build a clean bridge?”

On second thought, bridges are not built with the same methodology as software. Sure, there’s maintenance, but you rarely decide mid-way to scrap everything and start over. And you don’t really have the option to hot-fix your bridge at 3 A.M. on a Sunday because one of the structural elements has started to collapse.

Could it be that the clean code question actually has more depth to it than we think?

I’d say that the question needs to have a bit more context for it to be fair to the person answering it. A more honest question would be something like:

“What is clean code to you, if you’re going to be working on a 5–10 man team?”

When was the last time you wrote code that you absolutely knew would hit production and stay there for at least 2 years? Have you ever known that in advance?

The real irony is that, if you’re writing code all by yourself, you simply do not care about any of that. Does that mean you don’t write clean code? Maybe. Or maybe you want to get the job done as quickly as possible and move on.

Does knowing the answers to the above questions make you write “clean” code? I believe people want to write the best software that they can, but is it fair to say that, under peer pressure, they’d do a better job?

And after all, how clean can code be? How do you measure it? It might be tempting to answer with a phrase containing the word “bugs” in it, but I think everyone knows how that one plays out in the real world.

Perhaps you could measure the cleanliness factor of a particular block of code by measuring how much time it takes you to change it. But that also needs some context. Was the code written by you a week ago? A month? 2 years? Are you a Junior level software developer or a seasoned vet? Are you new to the project?

And how about business value? Is it profitable for your company to write clean code? Does a start-up exit faster if its code was written in such a way that it allowed a 20–50 man team to rapidly iterate on it and pivot according to market fluctuations?

I’m going to stop with the questions now, though, let’s draw up some conclusions.

It seems to me that measuring cleanliness of our code is hard. Writing clean code is even harder, of course. Talking about clean code, on the other hand, is surprisingly easy. Almost anyone can talk for hours about it.

And this is where I think the irony is: most people love the idea of clean code, would definitely write clean code given the opportunity, but have no idea how to measure code cleanliness or if this endeavor has any tangible business value.

I propose a new topic of discussion to everyone out there tackling the idea of clean code:

“How do we measure clean code, and what’s the threshold at which it starts generating business value?”