Being efficient in the perspective of writing new automation so you don’t have to do the same manual things again can easily make someone a 10x (or greater) engineer. This typically means writing your own tools and not hoping some third party package or framework will do it for you.
Conversely the same is true. If a 10x engineer is in an environment where they are prohibited from writing original tools they will just be average or much worse when their motivation is destroyed.
Ouch
The problem with this is that neither is good for your mental health. Unless you're joining that project with a specific goal of improving its development process, don't bother. Run away. Fast.
Especially if there are already other devs that are militantly against your take on dev process improvements. The level of emotional distress is hard to fully appreciate without experiencing a situation like this. Suggesting the simplest and most obvious things becomes a brutal fight that you're guaranteed to lose. Living without them makes you miserable in its own right. You're trapped between a rock and a hard place with no way out.
If out of various kinds of psychotherapy you pick the one based on an experience of living in a Nazi concentration camp as the most applicable - it's time to run. Really. Don't look back.
Also, some people just keep growing their creative outlook. They are not afraid to try solving bigger & bigger problems.
I worked with an engineer (individual contributor) at a company with a lot of related software products.
Time and again, he would hibernate then come out with a new well developed tool or product that either impacted the entire product line or started a new product line.
Once the value of what he had done was obvious, and his clever design had stabilized in a form understandable to others, he would hand it off to a team of great developers to polish, release, update etc.
10x impact would be an understatement.
If we measure impact, it is easier to see where 1x, 5x, 10x, or 100x can be achievable and verifiable.
Also x/2, x/10 or (and I have seen it) -x. One team leader, -5x at least, until they were removed.
But as a rule, it would not have been challenging enough to keep them engaged for long. And it would have been a waste of their talents for themselves and the organization.
It wouldn't just have wasted their time directly, but wasted the opportunity for less (but still A-grade) developers from diving into a new area and maximizing its value. There was still lots of creative work to be done. These were not trivial new areas.
The problem is many, many people are not in a position to advance that way. I've worked in startups where you're almost always given an ambiguous problem and rewarded for meaningful outcomes.
Many people are working as part of team/projects where the general problem and approach are already determined for them.
In relative terms, the unaided 10x engineer is now only a 2x engineer as his peers are now vastly more productive.
That's huge.
As an example, if you took away the top half of the engineers on my current team and gave the rest state of the art Copilot (or equivalent best in breed) from 2030, you would not end up with equivalent productivity. What would happen is they would paint themselves into a corner of technical debt faster until they couldn’t write any more code (assisted or unassisted) without creating more bugs than they were solving with each change.
That doesn’t mean the improved tooling isn’t important, but it’s more akin to being a touch typist, or using a modern debugger. It improves your workflow but it doesn’t make you a better software engineer.
And all this with documentation explaining what it did, and optimising the code for human readability, so that even with huge reworks you can still get the gist in a time measured in hours rather than it taking, what, weeks to do manually?
... but believing it is a theorem would be similar to believing that horoscopes can predict the future as well.
Maybe some day we'll have a model that can be trained to reason as humans do and can do mathematics on its own... we've been talking about that possibility for decades in the automated theorem proving space. However it seems that this is a tough nut to crack.
Training LLMs already takes quite a lot of compute resources and energy. Maybe we will have to wait until we have fusion energy and can afford to cool entire data centers dedicated to training these reasoning models as new theorems are postulated and proofs added.
... or we could simply do it ourselves. The energy inputs for humans compared to output is pretty good and affordable.
However having an LLM that also has facilities to interact with an automated theorem proving system would be a handy tool indeed. There are plenty of times in formal proofs where we want to elide the proof of a theorem we want to use because it's obvious and proving it would be tedious and not make the proof you're writing any more elegant; a future reasoning model that could understand the proof goals and use tactics to solve would be a nice tool indeed.
However I think we're still a long way from that. No reason to get hyped about it.
Knowing when and how to use dependency injection, making code testable, what to instrument with logs and stats, how and when to build extensible interfaces, avoiding common pitfalls like race conditions, bad time handling, when to add support for retries, speculative execution, etc. are part of parcel of what we do.
If ChatGPT can help raise the quality of work while also increasing its quantity, that'll be a huge leap in productivity.
It's not all there yet, but I've been using it to write some simple programs that I can hand out to ops / business people to help automate or validate some of their tasks to ensure the smooth rollout of a feature I've developed.
The resulting ChatGPT code--I chose Go because I can hand over a big fat self contained binary--avoids certain subtle pitfalls.
For example, the Go HTTP client requires that you call Close() on a response body, but only if there's no error.
The code it spat out does indeed do that correctly. And it's well documented.
It's far from perfect; I've seen a subtle mistake or two in my playing around with it.
I'm now no longer so much an author but an editor for basic stuff. I now have my own dedicated engineer with a quality level that oscillates wildly between fresh intern and grizzled veteran.
It'll only get better over time.
I have been skeptical about all this, but decided to play with using ChatGPT for coding a task I had. It wasn't perfect, either in workflow or in final results but what was clear was that not adopting it will very quickly make you lag behind your peers.
I think the additive bonus is especially high for senior devs who are fast, in that those will be faster in grokking the generated code and better at guiding it to the right solution.
I guarantee you that in five years anybody who cares at all about their productivity will be using it constantly in their workflow, probably much sooner.
A builder bot could then ask a series of questions and get permissions such as “can we use X package?”, and then update the specification before performing the build.
I know I could have used google but the way google presented me is not easy to find and digest, you have ads, you have article that is not exactly what you are looking for and the code examples are not exact. Gpt eliminates all that time and effort. It almost eliminates laziness
Still a good post and reply.
* Understanding the value proposition as a human, often as through a conversation; often with hidden criteria that you'll have to uncover
* Making sure the code respects the value proposition. As reading other people's code takes more time than writing it, ChatGPT won't help that much here.
----
One development to this story I'm anticipating for though is connecting ChatGPT to formal proof systems, and making sure it has sufficient coverage with 'internal thoughts' that are logic-verified (by opposition to killing the problem big-data-style). Sort of like the internal monologue that we have sometimes.
I say short and medium term we're sort of ok; but I don't know about 10 years from now.
Your two points may not be as sound as you think. The second one can be defeated now since ChatGPT is quite good at generating descriptions of what code is doing. The first point is more subtle, you can iterate on code with ChatGPT but right now you need to know how to run the code to get the results before providing feedback. Once tools are developed for ChatGPT to do that itself then it could just show the results and a non technical person could ask for follow up changes.
This stood out, so I looked it up, and it seems Richard Hipp is 61 years old. I guess it is more about the "any" than the "old". Or maybe old engineers are engineers doing it the "old way" (pre-chatgpt)?
Fabrice Bellard is utilizing transformer models for lossless compression, for example: https://bellard.org/nncp/
What a ridiculous dichotomy, or course there's plenty of room in between. The hard part might be articulating the problem, but the other part takes time. Make that part not take time and you can do more of the hard part.
This isn’t very conducive to corporate work though. It’s about timelines and features promised to customers.
I find I’m 10x more productive in the long term on projects I’m a sole developer on or when working with a small knit team. And I don’t measure that in lines of code or number of features.
I wonder if ChatGPT can help there.
Obviously not, it will just make expected windows shorter and shorter.
"This would take a C developer a month, but you use Java so 2 weeks should suffice"
"This would take a Java developer two weeks, but you use Python so a week should suffice"
"This would take a Python developer a week, but you use ChatGPT so I'll expect it sometime tomorrow."
The faster I've gotten at moving code around, the more subconsciously willing I've been to try something with a modest probability of working out, and more importantly the easier it's gotten to throw away a draft that isn't working out and try again.
LLMs haven't made it into my coding workflow yet, but I can see how they could be useful and the trend seems to be that they'll be in most high-octane workflows at some point.
+1 The readiness is all.
One "5X person" gets accomplished more than five "1X person":
Maybe that makes everyone hit that point easier, maybe it brings that point in for you. Not sure.
Smartness isn't wisdom.
AIs are, at most, producers of synthetic smartness.
of course a fast typer does necessarily make a good programmer
Typing will get you places faster, but some of the most productive tools we have don’t rely on it at all.
Slinging code is skills & tactics at best. It can only have a small multiplier.
All of it will reduce mental load for senior devs and enable them to tackle more problems or more difficult problems.
Not really though, at least not yet. I've seen some impressive results for trivial cases: the type of thing you'd see blogged on new web devs blog 10x over, but I've yet to see anything that wasn't trivial and worked come out of GPT.
In a winner-take-all economy, usually the winner is the person with the ability to do something the slowest.
Not always, but usually.
So, for example, someone who can productively spend 100 hours working on a blog post is probably going to get win out against someone who can only productively spend 5 hours working a blog post on the same topic.
And given a society where 99% of the rewards go to 1st place, 1% of the rewards go to 2nd place, and 0% of the rewards go to everyone else, having this ability is usually more valuable than the ability to pump out a little more work in some fixed amount of time.
Based on my experience, you’d be surprised how hard it is sometimes. I have a team of 10 engineers that failed to ship a basic CRUD UI after several months (and it wasn’t even close to done). Eventually it got taken over by one individual eng who finished it in two weeks.
Over my career, the higher up the pay grade I went, the less actual code I was writing and the more it was figuring out what to do, what's priority, how the existing code all fits together, evaluating risk, and how to make the right surgical incisions to accomplish the goals.
Glorious and quite rare is the moment when a problem is clearly written up by a PM and the codebase is greenfield or clear enough that just pumping out code is happening and taking up my day.
Most senior software engineers are less programmer and more analyst.
[1] https://en.wikipedia.org/wiki/Generative_pre-trained_transfo...
As you say, I find the act of writing code is hardly the bottleneck to my productivity. One of the best case scenarios, LLMs become the ultimate high level language. In that case, Software Engineer roles would switch from coding to more of a mix of old school Software Architect, PM and entrepreneur.
By the way, I find interesting to run the argument of "coding is not the bottleneck" in reverse. What if you design an organization so that coding is the bottleneck? How transformative would LLMs be?
When people claim ChatGPT can replace software engineers because it can sort of code is always puzzling to me. 20 years into this career, and writing code is only a minor part of my day-to-day activities.
A part I do enjoy doing, but still minor part nonetheless.
> What if you design an organization so that coding is the bottleneck? How transformative would LLMs be?
The funny thing is that although ChatGPT has been an amazing coding assistant tool, it can't meaningfully write code beyond boilerplate to me. I use it more as search engine on steroids, rather than actually relying on the code it writes.
A few times it even got into a hallucination loop going through different flavors of uncompilable code when I asked "how to do X using library Y", and refining the question was getting nowhere.
ChatGPT is an amazing tool that provides me value beyond the 20 bucks per month I pay. But still has far too many limitations. It's sort of funny to see people LARPing that it will kill knowledge jobs in the near term.
Design Patterns are said to compensate for features missing in a language (e.g. Visitor for multiple dispatch). ChatGPT is sounding similar - solving accidental complexity that "shouldn't" be there in the first place.
Stuff like
match network_foo_int {
TYPE_A => Foo::A(read_a()),
TYPE_B => Foo::B(read_b()),
...
Though I don't expect software dev job to go away. It'll just change in nature. Less typey typey, more managing the LLM.
There's also not orders of magnitude more existing data we can feed it anymore.
Not as a language model. Other leaps in technology would need to happen before it can code.
The problem isn't generating code. It's articulating a functional specification with enough precision and clarity that you can solve for the unknown, which is the program that satisfies the specification.
I agree with the conclusion that tools like ChatGPT won't be replacing programmers any time soon. And it won't be helping us to write programs until it can properly reason about the information it is trained on and prompted with. The problem with natural language is that it is often too imprecise. When you get to concurrency or optimizing data layout an LLM isn't going to understand anything about the problem space and the training data probably won't contain enough examples to produce something remotely plausible let alone good or elegant.
Writing, thinking, and asking the right questions will still be important for quite some time. We're not in the age of having a magical genie in our computers that can do all the work for us... yet.
Although using it as a procedural generation tool for fake data is nice... still not as nice as writing a property test with generators and shrink... but as a little time saver for quick prototyping, neat.
- Knowing or having control of the tools you use
- Knowing what problems are most important to revenue and which are the greatest risk
- Knowing the language well enough to plan ahead without much labor
When a company I worked at mandated an IDE it took me a while to be productive beyond typing speed. When I discovered my company had support for generators, I was no longer spending forever on boilerplate REST code. When I know my test harnesses well it's easier for me to prove functionality in a smaller feedback loop.
- Explanation/research ("how does this work?")
- Code analysis ("tell me if you think you see any bugs, refactoring suggestions, etc in this sprawling legacy codebase")
Things that feed into the developer's thought process instead of crudely trying to execute on what it wants
You are correct that I made an error in my previous response.
I apologize for the confusion I may have caused in my previous response
I appreciate you bringing this to my attention.
I apologize, thank you for your attention to detail!
Incredible technology, though. Feels like whoever decides not to use it will be at huge disadvantage real soon
I mentioned that an approach would be a lot of work. His response:
“It’s just typing. Typey typey type (makes fingers on keyboard gesture).” Absolute lightbulb moment for me.
To become a senior engineer is to realize that the code writing part is inconsequential as long as there are no technical unknowns in the work.
It’s freed me to try out huge sweeping changes just for fun and generally detach from my code. Sometimes I delete large, intricate changes so quickly and ruthlessly that my colleagues have to ask me to reopen them.
We aren’t paid to write working code. We are paid to grow harmonious systems. Working code is table stakes.
An org of a few hundred people at a big tech company many only have a couple of Individual Contributors making this much money.
I know it's unbelievable for those not in one of these companies, but this data is accurate: https://www.levels.fyi
but they are extremely rare
I make over $1m as a SWE. “Senior Staff” or “Level 7” role at a big tech company everyone knows.
I mostly write code! I am way faster than most others here, and I have encouraged and mentored the people on my team to be similarly efficient.
I also help decide technical direction but it’s far from the “architecture astronaut” stereotype that writes no code.
It’s an infra team so no significant influence on product direction, other than considering our frameworks and tools products. I do consider them in that way, but it’s still a big difference from being involved in the direction of the external product.
Timing gets a 10/10 for my $750k year at staff level though.
What were the main changes you introduced/points you mentored them on to get their productivity to also be similarly efficient?
I see people on other teams that seem to be stuck for days sometimes, on a really basic error that they haven’t really tried to debug at all. Seriously, just read the error message or dig into the code!
My team also has a strong culture of just pushing code changes. This is including tons of deletions and simplifications, it’s not just writing a million lines of code.
It’s also a very senior team, so I can’t take credit for everyone’s growth from junior engineers. Another part of it is creating an environment that productive senior coders want to join, so that they can avoid process-heavy teams and get stuff done.
There is an extreme level of trust on the team because everyone is senior and frankly extremely good at their job, which allows us to be even more productive.
With all due respect, you may have learned the wrong lesson — or missed some important context — and the above is a false dichotomy. Working code isn't just table stakes; it is virtually impossible to "grow harmonious systems" if you don't have solid working code, because without solid working code you cannot grow the system reliably.
The other thing to note is that just because someone makes a lot of money doesn't necessarily mean that they are good at their job, or that they are a good team player, or that the way they operate and the context they operate in applies to you. I know consultants who pull in a million or more every year, and you know how they do it? They write absolute shit software that, while fulfilling the contract requirements, ends up hamstringing the client down the line. Sometimes prioritizing short-term gains might be acceptable or even necessary (e.g. the auditor asks you to compile data from a bunch of sources and you need to do it fast), but for projects with longer life spans one should definitely not blindly "typey typey type".
I’d go further and say that in big tech, well factored well tested code is table stakes and the ability to produce it quickly is assumed. Junior engineers have to prove that to get their first promotion.
If that’s all they show, it will be their last promotion, and that’s perfectly fine too.
I grew up poor though and teaching myself coding moved be to earn more then I thought I'd ever earn without a college degree.
I knew about for loops almost a decade before I decided web dev would be my career, not just my hobby.
it's insane that you could get hired and not know how they work.
linked lists, sure. I still don't fully understand those lol, I was going for an associate's and that was in my c++ class but I've mostly only touched PHP, python, ruby, JavaScript... playing around with go and rust some as well, but I've never had to really think about linked lists, loops on the other hand is a daily thing.
hell, not knowing loops is like not knowing how to increment, like seriously, his to add 1 to an int.
Smh....
Even not-so-great-sounding contracts pay 50-65/hr, might be a confidence boost. Level up your skills on udemy, if necessary (wait for courses to be 80% off or whatever, happens regularly).
Could also go corporate at a non-tech for low stress and a decent salary.
I'm super obsessed lately w/ AI, on youtube, github, HN, reddit, etc... and working on actually building a clone of myself to do the mundane parts I don't like to do... hehe... this is kind of a green field, and the opportunities are huge, might be the last dev jobs when AGI hits -- training custom AGI's...
I've been watching the AI hype (again) and it's completely going over my head, I really really don't get it - I doubt {x}GPT would be able to analyze hundreds of thousands of project code across a big system (multiple languages, multiple services, interconnectedness of everything) and tell me what to do, even in the case I would want to paste in everything proprietary to a 3rd party service which I really don't.
Maybe it just works for a subset of programming, but then again I don't really see how it differs to reading docs for generating boilerplate or whatever it's useful for in greenfield projects. I was also not really impressed by it generating improvements to code when you ask it the right questions since that's the hard part of the job, not typing out the code.
Maybe I'm just a dinosaur and dumb.
Currently, the Language Models (GPT or GithubCopilot) are mostly good as ... copilots. You bounce off ideas off them or use them to kickstart something you want to do. It's great for junior devs (me!) but it still cannot do big context or cognition (what you describe), that part will be done by humans for quite a while.
Telling any AI system what to do will be the biggest problem. A lot of toy like algorithm problems can be easily stated. Stuff like inverting binary trees, sorting, and your myriad different Leetcode stuff is the easiest thing to do here.
Real world software has if/else statements peppered all over large code bases/domain logic. Lots of IO exceptions, lots of domain specific logic, all of this is nearly impossible to dictate in words. And even more you will eventually need some concrete way of describing things, which in all honesty will look a lot similar to code itself if you have to get it right.
Modifying code will likely be even more harder to describe in talk than in text.
That said, the real work is insight away from the keyboard.
I think your "what problems to tackle" is overlapping management or business strategy - though yes, it absolutely is the greatest multiplier.
Hyperproductivity in software is all about deciding what problems to tackle. Richard Hipp isn't worried about chipotle restaurant orders in golang, he's worried about how to store data reliably. That isn't a coding puzzle that ChatGTP is likely to help with. Either ChatGTP can do the whole thing itself (not yet the case) or it is a minor productivity boost because the hard part is articulating the problem.
Writing code quickly really isn't a challenge that high performing software engineers need to tackle. ChatGTP is a cool tool, we're all going to be using things like it in a few years, it'll change everything. But it won't make any old engineer a rival to the big names in software engineering.