I feel this may be too specific to your personal experience / work history.
Looking through some repositories of programs I like, some of them were prototyped in very little time, but with a surprisingly excellent first revision.
I had the pleasure to work with Zed Shaw quite some time ago, and even though his code might not be perfect, he writes a lot better code than the vast majority, in a lot less time.
Anyway, I think you need to look up the words "tirade" and "incomprehensible"
tldr: Welcome to the Internet
I have no idea if I write code better or faster than other people. Maybe I do, but I always think that I don't write very good code most of the time so I have to be extra careful. I spent a lot of time writing code very slowly and being extra careful so that I could make sure it's good quality. I guess after focusing on quality for so long I just got faster at it compared to others. But, I'm going to guess that I actually am not much faster than other people.
A big issue for AutoCAD was "don't lose the user's work". Customers were not forgiving of that. New features were less important.
Autodesk is still around, market cap around $26 billion. They're still selling expensive software that works, and have been profitable for over 30 years.
3d apps especially seem to suffer from bloat, which then leads to competitors getting the leg up and the original dying off; then repeat for the competitors.
If you want to be a great startup engineer you have to exercise judgement; knowing when to do something quick and dirty, what to polish, what code is likely to live a long time, when and how to address various aspects of scalability, etc. Someone who just has one mode of operation and does not consider the context is always a liability unless their role is very rigidly defined and management knows what they're doing.
I think most developers naturally become more cautious with experience (the bitter experience of debugging long into the night usually), while some never grok maintainability or documentation but can still be highly productive net contributors if you have a great testing team between their code and your customers
I've worked as a freelancer, lead front-end developer, and contractor, and ranging from 'stuck in the nineties' to 'use whatever HN talks about for the front-end' companies. One of the most important lessons I learned is to use the right tool for the right job. Also to not let 'purity' or 'elegance' get in the way of getting it done (which is difficult for me). But also to never confuse 'getting things done' with laziness.
Thankfully I'm pretty sure the startup would've failed no matter what, so I don't feel too guilty about it. But it taught me a valuable lesson.
Unfortunately for us mere mortals, programming is not quite a performance art (despite the existence of /r/watchpeoplecode), so there's not anything to point at globally as this is what a great programmer looks like.
Moreover, a company's culture is the culture - if they put up with assholes who can program a little bit, they'll also put up with assholes in be other positions for different reason.
Personally I'd choose somewhere else to work.
Showing results for /r/watchpeopledie.
Search instead for /r/watchpeoplecodeLots of us are good at being excited, moving fast, when something grabs our focus. Some of us are just as excited at the quality of our "how" as we are the size and shape of the finished "what".
The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degrading the code base. But their boss will love them because they deliver the shiny when required.
The second type are the ones who can sort out the mess created by the first type without making things even worse. They tend to be less visible, less well paid and less in demand but every company needs them.
The whizz kids and the grown-ups basically. Companies who only have the first will burn bright but not be able to scale. Companies who have only the second type tend to move too slowly to get to market or pivot.
So ideally there is a symbiotic relationship between the two types and someone who is a combination of the two is very rare indeed, because the first either needs an ability to place limitations on awareness of the big picture (and it’s very difficult to create a blind spot on demand once you have experience) or they need to be incredible at both analysis and full stack execution. Those people are few and far between so a process that gets the best out of the two types is, in my experience, the way that most companies work.