Drunk Post: Things I've Learned as a Sr Engineer

Maybe that's possible in theory but I've never encountered a statically language where I consider the testing frameworks "good enough".

Mostly public feedback (for only the good things, of course). Put their "good" code on code samples, documentation, code guidelines, tell the team "look everyone please do it like person X did here". It will surprise them in a positive way.

Also on PRs try to point to their own work as sample of how to do things better. This doesn't hurt the ego much, because the role model is themselves.

Also, I feel like most of the time this is an impostor-syndrome/perfectionism issue that also happens with other workers too, so HR can give tips on how to deal with those issues in a more sensible way and tell you what you can or can't say.

I'm not sure what to make of that. Maybe you just haven't bothered to look? You personally not knowing about something is a reflection of your own knowledge, and not of the state of the world.

That is an interesting aspect about rust I have not heard, and since over 50% of my C code tend to be about managing return codes with proper tear down, rust suddenly do look a bit more interesting. However doing a surface look, it seems that rust simply terminate the program when encountering some of the more critical return codes from syscalls, which does exactly feel like it solves the problem. I guess it is also a reason why the kernel might not switch to using rust any time soon, as oom should not cause drivers to just terminate hard. From my surface look, it also seems rust simply uses Result where in C you would store the value in an int, and both leaves it up to the user to read the manual and interpret the number into actually meaning. Of course I could be wrong.

In a way it also demonstrate a other line between when I would use shell, Python or C. With shell everything either existed OK or did not, and the return data is always strings, and so the programs written there is built with that in mind. With python I work with structured data, but I don't spend much work or thought on syscalls and what state the machine is in. With C, syscalls management and the state of the machine is the majority of the code. As such one pick the language based on what the code will be focusing on. Dynamic vs static basically becomes a shorthand for that focus.

> my experience [full-stack] means "frontend developer who can put together a basic API server"

This is 100% accurate in my experience too, and it's also true in the other way around: "full-stack" means backend developer who can put a basic SPA using React/Vue.

From the frontend perspective: they call themselves full-stacks for knowing how to spin up a NodeJS HTTP Server powered by Express with MongoDB inserting JSON in the database. But they are missing:

- AWS/cloud computing: not necessarily creating the infrastructure (although that's a must on more senior levels), but how to orchestrate the different components together.

- databases: why SQL/NoSQL, beyond basic SELECTs, knowing how to properly add indexes, debug why queries are slow, modeling, understanding locks implications and transaction levels, and so on.

- tooling: how to set up a bundler, linter and formatter, testing, CI/CD. This overlaps a bit with the responsibilities of the DevOps engineer, but a full-stack should know at least on intermediate level all of those things. I can't say how many times I've seen "senior full-stacks" that had no clue about how webpack worked at all.

From the backend perspective: they call themselves full-stacks for knowing how to spin up a React/Vue app that does basic CRUD operations using forms, powered by a UI framework like Material UI. But they are missing:

- CSS: most will find CSS hard/annoying and won't bother understanding at all how it works even on a fundamental level, will defer to hacks most of the time to make things work, especially when it comes to adjusting for edge cases like responsive design or cross-browser support.

- the DOM: normally they don't understand it at all, or to a very limited extent.

- Web vitals: how to measure and makes things faster and performant—not really including here overly optimized, but just making sure your app is 60fps or close to that most of the time. Usually when things get slow either on the network side or in the app itself, those engineers will blame is the framework/library, not their misusage of it.

--

Those lists are definitely non-exhaustive, as I didn't even mention more advanced stuff like protocols (how HTTP works? most can't answer), caching, etc etc, but you can get the point I'm trying to make:

The problem with the term full-stack is that only very few engineers really are sufficiently great on both sides of the stack and could say that they mastered both, simply because there's just too much to learn! Frontend has become so much more complex with SPAs compared when it was about rendering static HTML with some CSS and basic behavior with jQuery. Same for backend with the advent of cloud computing and several types of databases.

I've been coding professionally for a decade and I've met only a single engineer that I'd consider him full-stack (he checked all those boxes I mentioned and more). I think I would also include myself, because I spent 50% of my career spent as a front-end engineer, became senior, then I transitioned to back-end engineering because it pays the same or more and it's less stressful (for most of the regular companies that most of us work at). My current title is "principal full stack engineer", but in practice I only do backend/devops, I don't actively code front-end but I keep up with the industry by following the new trends and testing things here and there in personal projects.

Ultimately, I believe for being a full-stack engineer you have to be first a front-end (or back-end engineer) then learn the other, what we have today is most people doing the same from the very beginning of their careers and they either go deep on a single one or in none of them.