My Tech Skills

My primary learning direction is full-stack engineering with probably a frontend focus – I enjoy the complexity of full-stack applications.

Software engineering (in contrast to many other kinds of engineering) contains a widespread array of technologies that change extremely quickly. Hence, self-learning is very important and I believe that over a certain level of experience, one should know what they don’t know. Let’s see a rough assessment of what I learned so far in each area.

If you are curious, too, head over to some roadmap site like https://roadmap.sh/ and assess yourself – I’d be interested to know how your knowledge progressed over time. 🙂

Frontend engineering

Basic HTML/JS/CSS

90% – will write pixel-perfect HTML for food

Everybody mentions these when it comes to frontend development. I can write and easily navigate vanilla HTML/JS/CSS, with or without frameworks, even if it’s not really needed today. I love latest CSS stuff such as flexbox and grid, and occassionally used CSS preprocessors like SCSS.

I try to write semantic, HTML at all times if possible, even if using some framework to abstract away the details. I focus on accessibility For JS, I mostly use and prefer Typescript for added type safety, but personally dislike its class syntax.

Next up: just keeping up with the latest JS language improvements. Each year the web is getting farther and farther away from vanilla HTML/JS/CSS.

Frontend frameworks

80% – I know the ‘big 3’

I can use and have had projects in Vue, React and Angular, probably in this order of preference. I see the similarities and the core differences between these frameworks and could teach how to use them to any developer.

State stores are preferred by me if app complexity reaches a certain (not so high) threshold – I have used Ngrx, Vuex and Redux. I also occasionally use some simpler templating libraries like handlebars.

Uncharted: I lack experience with mobile app development such as React Native.

Next up: keep up with new frameworks and keep an eye on truly new ideas like Svelte (which promise faster apps and better development flows but are not quite yet ready for larger-scale apps). IMHO the functional syntax of React hooks (and probably the upcoming Vue 3.0 composition API) will stick with us for a while.

Frontend architecture

70% – will have a good attempt at building your app

I know how a frontend app is built up and can bootstrap it quickly with some tooling like CRA or Yeoman. I could even configure Webpack but like most sane people, I don’t want to.

I can architect small to midsize apps with relative confidence, including API use, authentication, services and even some Websocket.

Tests are useful, and I enjoy using Jest for component unit/integration tests and Puppeteer for end-to-end testing.

Next up: I don’t have much hands-on experience with SSR or GRaphQL yet, but it’s just one learning step away from my current knowledge level. These are more like niches that are good to learn but not used everywhere.

Backend engineering

This is an interesting part, especially that there is no ‘definitive’ backend framework or language like the HTML/JS/CSS trinity for frontend. Instead we have a lot of languages, ecosystems and even more custom architectures. So rather, we should approach this assessment from a domain perspective.

OS/runtime environment basics

70% – will hack anything with a terminal, but get stuck in MS world

I’m a *NIX guy. 🙂 Adept at using Linux systems, terminals, services, SSH tunnels, scripting shell. I don’t have much Windows experience though.

Uncharted: for me, Windows is a peculiar OS necessary to be used when playing some recent games. I could maybe learn some WSL or Powershell but don’t really feel inclined to do so.

Databases

60% – hire a database engineer if it’s more than using SQL/Redis

I only have PostgreSQL experience, quite much of that. I understand basic ACID principles and can do a lot of stuff that a software engineer needs to do in their everyday life: write some schemas, queries, SQL scripts, migrations, even PL/SQL functions. If performance issues arise I can look at logs and execution plans and maybe come up with some optimization ideas such as better indexing.

Next up: this is cool, but far from being properly trained in this area. Also, I could get some noSQL and in-memory DB (Redis) experience.

Backend architecture & APIs

70% – I understand backend architecture and microservices challenges

I know what backends do and have interacted with architectures from dead simple monoliths to ultra-scalable enterprise-grade stuff with complex message queues. There’s a lot of buzzwords, philosophies, languages, technologies and architectures out there.

Even more than for frontend, which may be chaotic and overhyped at times, but ultimately it’s mostly for presenting stuff – so it’s easy to see if something works fine or not. For backend though… It’s hard to cut through the noise of hype and corporate b*llshit language to see real value. (On the contrary, these technologies tend to change slower.)

Some systems I’ve worked with were doing their job quite fine, some were awful legacy code or over-engineered spaghetti based on custom frameworks solving problems that shouldn’t exist in the first place. But at least they created jobs. I digress.

Today, everything revolves around REST APIs and microservices – they often work great with web apps. I could architect less complex CRUD-like backend systems but still lack the experience to eg. optimize performance scaling or mitigation strategies in complex enterprise architectures myself.

Uncharted: I got into the game too late (or in the wrong place) to deal with XML & SOAP APIs. Have I missed something?

Next up: get into the right position to work with more complex architectures and learn as much as possible from more experienced software architects. Learn more about message queues, why not.

Backend languages

70% – NodeJs, Java, some Python

I know that experience with languages matter, but just as I don’t believe in buzzwords or frameworks, I don’t believe in languages. I know only a few backend languages and frameworks, but know what they are supposed to do so I can get up to speed relatively quick.

  • Java: mostly Spring, especially WebFlux.
  • Javascript: I have used Node.JS extensively, without any more complicated framework, just plain Express & Koa.
  • Django: I have recently picked up Django for some backend projects. It’s opinionated like crazy, but does the job wonderfully.

Next up: I unfortunately don’t care so much about languages unless they contain fun stuff like type pattern matching, immutability or expressive functional syntax. Most don’t.

Devops, version control, build pipelines, CI/CD, metrics

50% – not a devops engineer and will probably not write your Jenkins pipeline.

But I can write a Dockerfile, set up a Git repo with some nice workflow, configure Docker-compose or even set up a metrics collection system like Prometheus or Bosun with Grafana dashboards. I can interact with Linux-based devops systems, modify HTTP server or proxy config etc.

Uncharted: AWS. I only used some custom Kubernetes implementations.

Other domains

Computer science

60% – will optimize your algorithm, but don’t make me write your shiny new custom compiler 😜

Well, I started out as a different kind of engineer (mechatronics). So I actually have good formal education in certain aspects of maths, physics, control systems, mechanical, electrical & simulations engineering… all slowly becoming obsolete in my head. But we did learn some about ML, neural networks, image processing, analog & digital electronics and certainly quite a bit about robotics & embedded engineering.

Since I started software engineering, I have picked up some theory on programming languages, algorithms and computer security. It’s great to be able to assess algorithmic complexity and bottlenecks of business logic, and to see behind the curtains of programming languages.

Uncharted: ML/AI.

Next up: there’s still quite much to discover here. Look at some lambda calculus because it might enlighten me? (Kidding.)

Cybersecurity

60% – I won’t (yet) do offensive security checks for you but will write and maintain projects that are safe from common vulnerabilities.

I of course know about stuff like OWASP top 10 vulnerabilities and have implemented JWT, oAuth and other authentication methods. I can setup protections like CSP, CORS, CSRF and HSTS for basic security.

Nevertheless, cybersecurity is more than that: it’s about being able to design and implement usable and secure applications, not merely just about assessing vulnerabilities.

For the last year or so, I’ve been working as a ‘security champion’ in my team, fostering good security practices and conducting security reviews of our projects with security specialists.

Wrap up

That’s a long list and it was great to contemplate on my engineering journey so far. It seems that I have progressed a lot. Companies call me a ‘senior engineer’, but I also don’t believe in titles 🙂 since they are… just titles.

For me, seniority as an arbitrary level of competence mostly means that I kind of know what I don’t know.

In fact, if I went to a job interview today, anyone can make me look like a total failure if they asked the right questions. Of course they would learn what I don’t know instead of learning anything about what I do know.

Problems rarely need to be solved in five minutes at an interview setting or at a whiteboard. Have I said that I also don’t believe in job interviews? 😉 But that’s another topic!

See you next time!

Share this post