From Nothing to One of the Best Frontend Javascript Jobs in Berlin

Alexander Jeffcott 26 September 2020

How I switched career and got good enough to start working for AMBOSS.

It was 2015 and I was in Berlin noodling around with making games with Unity in C# — at least when I wasn’t trying to teach business professionals and civil servants to communicate better in English. I’d been doing that for about a decade and it had served me well, but when I got a gig teaching a bunch of developers, I suddenly realised that there was simply nothing that I wanted to do more than software development. When I was talking to developers about what they were working on — their struggles as well as their triumphs —I couldn’t help but be inspired to change my life.

This all crystalised when a lawyer I knew told me about a great idea for a legal tech service. He’d been trying to get it off the ground but had stalled on the tech side and the project had all but gone stale. So I sat down with my wife — a Fullstack with a decade of experience — and built a prototype.

We built it with jQuery and it worked. But then we wanted to do better, so we rebuilt it using AngularJS (aka Angular 1), and that worked too. Then I wanted to take it even further (my wife left the project at this point to concentrate on her day job) and rebuilt it again with React 15. These three sentences don’t really convey the sweeping moments of glory and despair — or sheer hard work — contained in the days and weeks themselves, but it really reflects what is for me a key and bittersweet part of developer work: the joy of fulfilling or exceeding a goal in code is quickly joined by the drive to do better.

Baby Steps: From Zero to My First ‘Proper’ Job.

In the mid-summer of 2018 I managed to get my first fulltime-with-a-team-of-other-developers job as a Frontend Developer. But I get ahead of myself — it is still 2017.

Since launching the legal tech app, I had spent about a year taking on small freelance projects while building knowledge. To generalise, during this time I was doing three things:

  1. Getting as much time working with Senior Fullstack and Frontend developers as possible.
  2. Spending about ten hours a week in front of my keyboard with the likes of The Net Ninja and Traversy Media and everything I could find in PluralSight.
  3. Spending a good 60 hours a week hashing out and getting to production a non-trivial project — the Legal Tech React SPA.

Looking back, the first activity did more to help me feel confident than teaching me specific skills. This isn’t because working with more experienced people isn’t useful, it is just that the projects tended to be pretty small, not much more than trivial. The second was invaluable as you do have to pull new knowledge from somewhere! But it was the third that really made the difference. It turns out that learning to be a developer is not just about learning skills and practicing them, but also entering the right mindset, and this first production project was perfect for getting into it:

  • It was very nearly more than I could handle at the time in terms of complexity.
  • It was public-facing.
  • It had had non-technical stakeholders and collaborators including marketing, design and a PM.

These things pushed me to take responsibility for “details” that many developers who are starting out don’t have to think about for a long time. Things like:

  • Browser compatibility and responsive design
  • Performance
  • SEO and enabling effective marketing
  • Accessibility
  • Privacy compliance
  • Scalable user management
  • Scalable database design
  • Creating an automated CI pipeline
  • Full internationalisation and translation
  • Animations
  • Automated e2e and unit testing
  • User flows and UX
  • Pixel perfect graphic design implementation

While many of the above were difficult and I remember wishing that I didn’t have to deal with them so rigorously, there were many times that I would have liked to take some shortcuts and focus on what was preferable to ME as a developer. Being forced to polish a prototype to production gave me invaluable experience that would make me a better developer and a better teammate. Building the biggest and most difficult piece of software I could showed me the importance of good practices in a way that being coddled in a company couldn’t have: I knew that I was on my own and that I had to do the best job I possibly could.

Similarly, taking the project all the way to users raises the bar on quality in a way that mere diligence generally does not. I spent many hours thinking about and ensuring that the UI worked as expected across browsers and viewports. How many hours would I have spent thinking about and experimenting with button placement and design were it not for this project? Far fewer, it is certain. I consider this to have been absolutely invaluable and I see many juniors struggling to get to the next level, but they rarely force upon themselves the challenge of taking ownership of the broad strokes and the minutiae.

So back to the stinking hot Berlin summer of 2018 — I had spoken to a couple of recruiters who had contacted me the second I changed the title on my LinkedIn profile, and I had been working hard to manage expectations of my experience. I eventually found a position that I thought was suitable and went along for the interview. They offered me the job then and there and I took it.

Stepping Out: Outgrowing My First Role

It quickly became clear that it was going to be one of those key periods in life that is looked back upon ruefully as instrumental, albeit one that would not last long. In other words, it was a nightmare of drama and bad practices, so I gave my notice shortly after my contract was confirmed. But where did it leave me?

I had gained eight months of valuable experience that I could not have obtained alone. I had been working closely with a team of mobilers, frontenders, backenders and DevOps and had grown familiar with tooling and workflows which are standard in engineering teams:

  • Jira
  • Confluence
  • Source Control (in this case Bitbucket)
  • Jenkins

It may sound silly because gaining a basic understanding of these tools is pretty simple. But, like CSS, the 3o minutes it takes to understand the syntax is ~1% of what you need to know to have a chance of being good at it. Seeing how these tools fit into the larger scheme of your team and department and the product you are working on cannot be easily achieved alone or even with a handful of people. To get a real appreciation of these tools means working side-by-side with people with various skillsets and levels and habits and flaws. As an example, while working on my own or with one or two other developers, I had never had the need to git stash — little did I know that this would be a regular part of my git day!

I took these experiences and re-entered the job market and found the best job that I could. A great team with a great digital product at a company called AMBOSS.

Summing it all up

It was a long road to get here, but I can happily say that every step was worth it.

Thanks to Elias Liedholm