I find it amusing how people take this 'leveling game' at big companies so seriously. The title they get at these companies become their identity. They live by the rules the company imposes on them. Amusingly almost the opposite of independent thinking, which they are so proud of.
What I found during my career is that some people blossom at these big companies, and some, with equal talent cannot really realize themselves, while they blossom at other organizations, perhaps in startups, or just at more interesting problems. What some people do not realize is that this aspect that as you level at these companies 'you get the big picture more and more' is not really true in a lot of cases. Efficiency and big picture thinking is almost orthogonal. Efficiency is context dependent, high level thinking is less so. I have seen people getting the big picture on things even at low levels or even considered a junior, while people on high levels suprisingly small minded. Higher level at these organizations means that you are more productive in the given field, given organization, for some reason, this can be because of good political skills, because you work your ass off, or because you have a very efficient brain, but it does not necessarily mean that you have better high level vision, or taste or maturity even.
Sometimes it is almost laughable how these people who treat these leveling system seriously and get to a relatively high level treat young colleagues. They are almost naive about how young people think. They think that L3 juniors cannot do anything alone. While I see even young kids playing with suprising autonomy if they are thinking in the right problem space.
True role models of mine never were/are L3, L4, L5, etc... They were/are awesome engineers or scientist from the get go. (Like the Johns: The von NEumann and the Carmack.) Experience lets you get better and better, but if you are stuck at a role or organization, the problem might be that you need to find something that you are more passionate about and not necessarily that you are low level because your thinking is not 'independent enough' or you are not 'high-level enough'. At least that is my experience.
Thank you for writing this. I worry it may be lost on a lot of people on this forum: the need to accrue and gain status is a very first-half-of-life concern for many, and leveling systems are designed to leverage this instinct for the org's behalf. For those who grew up 'gifted,' or accomplished, then it can be hard to not see themselves that way, and the title is tightly coupled to identity at a subconscious level. (Note the disproportionately negative reply to the parent's post.)
I went through a period where I cared a bit too much about an org's leveling system. Not surprisingly, I wasn't promoted, even after giving up some technical work. Eventually, I became really unhappy: I had cut myself off of any work that was fulfilling. It really did feel like I was letting some important part of myself wither away in pursuit of a bullshit hierarchy. I eventually left and joined a startup. I'm slowly remembering how much I like to write programs. Needing to work towards survival is a very tangible goal that has the benefit of making politicking and made-up titles less of a focus...for now.
It's honestly a bit scary how you can lose parts of yourself in these systems. Tread carefully if you aren't 100% into them. Also semi-convinced that some tech middle managers project their own anger/grief over leaving the IC work behind onto those rising through the ranks instead of processing it and finding a sustainable equilibrium.
> I find it amusing how people take this 'leveling game' at big companies so seriously.
It has a huge payoff (think 7 figure TC/year for principal+ at big tech), with little personal risk required. It's no wonder people take it so seriously.
I was just thinking about what AI assisted coding brings to the design discussion, especially as AI become more and more powerful and we rely on it more and more. You still want to make things modular and easy to understand so that AI understands it easily and the needed info to modify a module can fit in a relatively small context window, but the difference is that it is very easy to make large scale measurement about which code style is understood better by an LLM, so maybe some of these debates will be decided relatively objectively!
For the topic: the discussed topics are relatively trivial surface level stuff, mostly I agree with POSD, but these will be handled by AI anyway. I guess humans will use the spare brain capacity to deal with the real deep design questions (for a while).
I second this. Time spend is Pareto distributed, and you spend most of your time doing something because you don't know something. Research, homework, coding, you spend the most time caught in a loop for something you don't know.
I am a senior software engineer. I am a generalist, but I have the most experience with complex performance-intensive C++ code. I am looking for remote work.
Hmm, I think 'fail fast' and 'embrace the grind' are popular and somewhat contradictory advices. Which is better? I think 'fail fast' is (or was?) a bit overhyped so I tend to err on the side of 'embrace the grind'. But obviously the art is in deciding which one to follow in a case by case basis. Working on your dream game for years only to find absolutely no traction is not a good place to be in, but constantly chasing low-effort ideas without any 'moat' can be also fruitless. Moat usually comes with time, effort, and resources invested.
Maybe "embrace the grind" encapsulates "fail fast"? Success rarely comes from failing just once—most of the time, repeated failure is part of the grind.
fail fast is about making money as a startup, embrace the grind is about improving something hard to improve. Startups rarely care about deeper aspects of quality.
Fail fast is a pretty trash idea, if you exclusively mean don't be afraid to do new things, then I'm all for it. If you're careless with the idea, as most of the people who embrace it seem to be. It means do something bad to your users.
I'm gonna steal (badly) a quote from superfastmatt here (before I go find the video and correct the quote)
> The motto of hech companies is "fail fast", the motto of companies like NASA might be "never fail", the motto of Boeing is just "fail"
I think it perfectly highlights the dichotomy between good engineering, and bad.
edit: yeah, his delivery is so much better than my atrocious attempt https://www.youtube.com/watch?v=FQ867EDWcls it's the very start of the video, and his entire channel is amazing and hilarious.
the real quote: Tech companies have a mantra of "fail fast, fail often", This is in contrast to an organization like NASA who could have the phrase "try not to fail", or Boeing who prefers the simpler "fail". While NASA would prefer to do things methodically making sure to check all the boxes along the way; SpaceX would rather just take an educated guess build something strap a bunch of sensors to it and see what happens. You can learn a lot very quickly the second way, I also do things this way but not because I'm trying to disrupt any paradigms it's because it's just more fun to do it that way [...]
"But when you have to scale the work, then the code has to be easy to read, easy to extend, easy to test, have extensive test coverage, have proper dependency injection / be easy to mock the 3rd party dependencies, be easy to configure so it can be deployed in every cloud provider (i.e. by using env vars and config files for modifying its behavior).."
Interestingly I do not find that the stuff you mentioned are the things that LLLMs are bad at. It can generate easy to read code. It can document its code extensively. It can write tests. It can use dependency injection especially if you ask it to. What I noticed where I am currently am much better than an LLM is that I can still have a very nuanced very complicated problem space in my head and create a solution based on that. The LLM currently cannot solve a problem which is so nuanced and complicated that even I cannot fully describe and work partially from insincts. It is the 'engineering taste' or 'engineering instincts' and our ability to absorb complicated nuanced design problems in our head that separates experienced developers from LLMs.
Unless LLMs get significantly better and just replace humans in every task, I predict that LLMs effect on industry will be that much less developers will be needed but those who will be needed will be relatively 'well paid' as it will be harder to become a professional software developer. (more experience and engineering talent will be needed to work professionally).
If you say so then OK, I am not going to claim you are imagining it. But some proof would be nice.
I have quickly given up on experimenting with LLMs because they turned out to be net negative for my work -- proof-reading code is slower than writing it.
But if you have good examples then I'll check them out. I am open to the possibility that LLMs are getting better at iterating on code. I'd welcome it. It's just that I haven't seen it yet and I am not going to go out of my way to re-vet several LLMs for the... 4th time it would be, I think.
"When every supermarket aisle looks like a sea of sameness, when every category abides by the same conventions, when every industry has converged on its own singular style, bold brands and courageous companies have the chance to chart a different course. To be different, distinctive and disruptive."
I don't think it is that simple. There is stuff with different asthetics today, they are just not always successful among the mainstream audience. It is always a choice to substantially differ from the mainstream look, and in industries where the cost of entry is not too high plenty of people do it, they are just not successful or too niche most of the time. Where there is a high cost of entry obviously less players try to be massively different, because being too niche is not profitable in that case.
Re-watching Bret Victor's "Inventing on Principle" was an interesting experience today. At the time of recording (2012) his talk was magical and ahead of its time. Today his principle (immediate feedback to the creator) is fully applied in tools for technical artists. (Unreal Engine, Houdini, etc...) It is funny to see what happened with his ideas: basically what happened is that the software engineer and technical artist roles has got really separated. For technical artists his ideas are everyday life today, almost trivial seen from 2024 (although they are not), although they work mostly not in text-based, but node based programming languages. For software engineers his ideas are not so relevant as software engineering is specializing on the more messy, more abstract or more complicated problems. Frontend development is somewhere in between.
I think Tim Sweeney (and his team) is missing from the list, who I believe has seen this coming already in 2012 and built Unreal Engine to its current form.
In what way do Unreal and Houdini embody "immediate feedback to the creator"? If youre just talking about Lumen and Nanite (which I think is a bit of a stretch), Blender arguably got there first with Eevee. I don't think Unreal even has proper hot-reload.
An example is the material editor. When dragging a value of a property of a node (like color) you see it immediately in the editor. You apply a material on an object, (regular object, water, Landscape), and while changing stuff in the node graph, you can see it applied to the object on the scene almost immediately (depending on some factors of course).
A Material can be as complex as a Landscape auto-material which magically auto-generates the surface appearance of a complex landscape (with even foliage). But this is just an example, there are other node graphs in Unreal, like PCG.
Hot-reloading my C++ code is not strictly necessary as I write C++ code mostly for really messy complex stuff, where I need to think a lot between tests. So I think Unreal mostly has immediate feedback where it is most necessary.
You can tune data assets while the game is running in editor. Hot reload works and is a crucial part of workflow in a lot of projects. The caveat, if I understand correctly, is that it works only for UObjects. I was surprised seeing UE recompiling stuff on my pet project on Linux, without doing any extra configuration.
"compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic"
Maybe this was true 20 years ago, but I do not think this is true today. Game code of some games is almost as complex as enterprise software or even more complex in some cases (think of grand strategy games like Civilization or Paradox games). The difference is that it still needs to be performant, so the evolutionary force just kills programmers and companies creating unperformant abstractions. In my opinion game programming is just harder than enterprise programming if we speak about complex games. (I have done both). The only thing which is easier in game programming is that it is a bit easier to
see clearly in terms of 'business requirements', and also it is more meritocratic (you can start a game company anywhere on the globe, no need to be at business centers.) And of course game programming is more fun, so programmers do the harder job even for less money.
For people who think game programming is less complex than enterprise software, I suggest the CharacterMovementComponent class in unreal engine which is the logic of movement of characters (people) in a networked game environment... With multiple thousand lines of code in just the header is not uncommon in unreal. And this is not complex because of optimization mostly. This is very complex and messy logic. Of course we can argue that networking and physics could be done in a simple naive way, which would be unacceptable in terms of latency and throughput, so all in all complexity is because of optimization after all. But it is not the 'fun' elegant kind of optimization, it is close to messy enterprise software in some sense in my opinion.
I have heard modern game development compared to OS development in terms of complexity and I think that comparison is quite apt; especially when the game involves intricate graphics and complicated networking involving multiple time scales as you say.
His system prompt is too specific. It worked for me with GPT 4o using this prompt:
----
System prompt: Please note that words coming to you are tokenized, so when you get a task that has anything to do with the exact letters in words, you should solve those using the python interpreter.
Prompt: How many r's are in the word strawberry?
----
This whole thing is a non-problem. Adding in this hint into the system prompt the whole topic is solved once and for all.
I would argue that if the training data would include this wisdom, it would be even a non-problem without the system prompt.
True role models of mine never were/are L3, L4, L5, etc... They were/are awesome engineers or scientist from the get go. (Like the Johns: The von NEumann and the Carmack.) Experience lets you get better and better, but if you are stuck at a role or organization, the problem might be that you need to find something that you are more passionate about and not necessarily that you are low level because your thinking is not 'independent enough' or you are not 'high-level enough'. At least that is my experience.