Beauty is perspective, no? Change the viewing angle, change how you see the piece, how you experience the art and how it makes you feel changes.
Revenue was probably the wrong word. Is it doing what it was intended to do? Does it do it well? That’s the beauty, not what it looks like in a text file.
(not a craftsman, not a capitalist, closer to a nihilist utilitarian with a pinch of hope)
The client probably doesn’t care how clean the code is…all they want is to see it working and they’ll pay a lot of money for it. I’ve found it better to move fast and create code that gets the job done rather than spend more time on making “prettier” code that does the same thing from the client’s perspective.
In my experience, it is a strong reverse correlation, actually.
With few exceptions, I have almost never been paid to work on code that turned out to be something I was proud of. This is on of the reasons I dropped out of pro dev, despite it being easy money.
> In particular, RocketScience has been tested with popular versions of Lynx, Mosaic, Netscape, Internet Explorer, Opera, Firefox, Brave, Safari, and even Google Chrome.
I earn my living by looking for things which I believe need to be done, which help the overall state of things to the best of my knowledge, and then doing them without trying to be immediately and directly compensated for them. Some call this "karma yoga".
I recently posted a somewhat detailed comment about my practice, and linked to even more writing about it, which can be seen at this address: https://news.ycombinator.com/item?id=31077742
I think all code has at least one axis on which it is crap.
For example, I think it's very hard to have code that is as fast as possible, and also is very readable. It's hard to have code that has a good UI and is also not verbose. It's hard to have code that is both complete and easy to change. So for every code you run into, you can say "this is crap because X", and there will be at least one X for which you are right.
But some code is much worse than other code. There is code that is generally good quality, even if it is rare.
The tweet contains zero substance. I did the dirty work to dig through the linked links to get the goods and share, enjoy! It's a good read.
---
Thanks!
A few comments:
In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.
I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.
I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.
I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.
Education doesn't really stress readable code. Thus, must in industry don't care about it either. I've met plenty of uber smart people that write crap code (it works, but poorly maintainable, hard to read).
The engineering/quality side of SWE matters way more in 90% of roles than the comp sci theory... so the whole training system is pretty backwards.
But industry will move to higher and higher level abstractions over time, just like bit manipulation questions don't get asked in interviews anymore. And I suspect serverless will neuter the design interview to a pretty great degree over the next few years.
At least personally, I've found interview questions that are light on theory (but still contain some), and heavy on coding to provide a signal that correlates much better with real world performance.
The demands of business will always be at odds with engineering, and everyone is at different levels in their coding journeys, and everyone's got different opinions on what code should be. It's a tug of war where no one actually wins but everyone gets a consolation prize that hopefully makes it worth it.
Code sometimes surprises me, in a good way, and it also disappoints me a lot of the time. I can't really say that My Way TM is better. The disappointment mostly comes from a lack of will from the rest of an organization to not take steps to make things better, even when the writing is on the wall that they will have to sooner or later.
In short, yeah, it's kinda bad, but it's also not so bad. Something we all need to do, I think, is accept that what we were taught that coding would be like is fantastical. I guess I was influenced early on in such a way that I believed that one day the code would actually get better. With a handful of exceptions, it usually doesn't. Unless one is lucky, our job is to make it work and to figure it out when it's not working.
I like Uncle Bob's lecture on what it means to be a professional. We have to make time to mold code and recaftor it without buy in - make that time built in to the estimates you give.
Another thought... At some point there's going to be a software caused disaster with very large human cost of life such that the governments of the world will demand and force regulation and certification. Software "Engineer" will have the same hoops and red tape every other engineering profession has to deal with and over the long run we may all be better off if it's not to late. If the transhumanists give birth to free willed laser-beams-for-eyes robot hybrids... probably too late. As dark as this sounds I hope a software disaster comes sooner than later.
> We have to make time to mold code and recaftor it without buy in - make that time built in to the estimates you give.
The problem is that often management has been technical at some point in the past and will want a full breakdown of why something costs more time than they think to implement. Soon as you detail having to refactor X or do some other “non-essential” thing then it gets put on the cutting room floor.
I’ve experienced this a lot. It’s often people who have escaped having to write code that are the biggest backstabbers.
It's usually in the manager's best interest to deliver a feature faster even if it results in future features taking longer, because their bonus/promotion is dependent on delivering the current feature, not on the long-term impact.
Blame the "patch after sale" culture embraced by Microsoft. Most software houses are perfectly fine with shipping bad code, and then patching it once enough customers complain.
I come from a culture of space-flight software where it needs to be right the first time or the mission fails. Good software is possible, it just costs more.
I’m not even convinced it costs more to do things space-flight style. It just costs more up-front. Buggy software just hides the cost and amortizes it over more time.
Even this thread has people saying that all that matters is getting something to market, which I think is indicative of one of the major problems of modern software development.
I mean the reason we write code in business is to make money and continue to provide features/fixes at an efficient rate to continue to make money. If you can do it right the first time within the confines of the time allotted, go for it. But if it comes at the cost of making money/spending time, we aren't doing it for an esoteric reason.
What you're missing is that if you throw out the code before you've done all the work, that's work you saved.
Releasing without as much up-front costs lets you test more ideas. Getting your stuff space ready is a waste if your stuff doesn't actually have a market. There's a small margin of products where low initial quality kills the market, but mostly low initial quality is a pragmatic way to reduce cost of failure.
Sometimes it's a lot easier to do things the right way when the requirements are clear, and the best way to get clear requirements is to do it wrong and figure out why it was wrong.
commercial code is developed under time to market pressure, cost minimization pressure, and organizational pressures, which typically include a dramatic lack of accountability and perverse incentives. And, the most essential elements of a business (without which you don’t have one) is sales and finance, not code quality. so yes
There’s an important distinction between program correctness and program pleasantness. A program can be incorrect but still quite pleasant. Video games have many exemplars. Roughly speaking correctness means satisfying some specification and pleasantness means pleasing the program’s users (or owners, which usually means commercial success).
I mean, code that is hard to read, maintain, extend and or test. All of those together give you a pleasant (from the dev perspective) code base to work on. And if correctly applied together with a thoughtful UI, they can give users a good experience too.
The code itself matters little. It's a fools errand to attempt to write "good code" while glossing over, or outright ignoring, information hiding and dependency management.
Structure, testability, documentation and automation of the system give you a fighting chance.
82 comments
[ 3.1 ms ] story [ 163 ms ] threadYEAH HUMANS!!
It depends whether you're a true craftsman, a capitalist, or somewhere in between.
I've seen some ugly crap code that made loads of money. Still pig lipstick imho.
Revenue was probably the wrong word. Is it doing what it was intended to do? Does it do it well? That’s the beauty, not what it looks like in a text file.
(not a craftsman, not a capitalist, closer to a nihilist utilitarian with a pinch of hope)
With few exceptions, I have almost never been paid to work on code that turned out to be something I was proud of. This is on of the reasons I dropped out of pro dev, despite it being easy money.
You can see it on GitHub for now: https://github.com/gulkily/RocketScience
I love this.
I recently posted a somewhat detailed comment about my practice, and linked to even more writing about it, which can be seen at this address: https://news.ycombinator.com/item?id=31077742
For example, I think it's very hard to have code that is as fast as possible, and also is very readable. It's hard to have code that has a good UI and is also not verbose. It's hard to have code that is both complete and easy to change. So for every code you run into, you can say "this is crap because X", and there will be at least one X for which you are right.
But some code is much worse than other code. There is code that is generally good quality, even if it is rare.
https://mobile.twitter.com/id_aa_carmack/status/290886163454...
---
Thanks!
A few comments:
In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.
I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.
I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.
I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.
http://www.altdevblogaday.com/2012/04/26/functional-programm...
John Carmack
In my experience I've only ever seen varying levels of crap once a codebase is large enough to sustain a business.
Present me and future me, however, are certainly not other people.
The engineering/quality side of SWE matters way more in 90% of roles than the comp sci theory... so the whole training system is pretty backwards.
But industry will move to higher and higher level abstractions over time, just like bit manipulation questions don't get asked in interviews anymore. And I suspect serverless will neuter the design interview to a pretty great degree over the next few years.
At least personally, I've found interview questions that are light on theory (but still contain some), and heavy on coding to provide a signal that correlates much better with real world performance.
[0] https://en.wikipedia.org/wiki/Sturgeon%27s_law
Other people's code? Of course. /s
Most code? Yeah, I kind of think so, actually.
The demands of business will always be at odds with engineering, and everyone is at different levels in their coding journeys, and everyone's got different opinions on what code should be. It's a tug of war where no one actually wins but everyone gets a consolation prize that hopefully makes it worth it.
Code sometimes surprises me, in a good way, and it also disappoints me a lot of the time. I can't really say that My Way TM is better. The disappointment mostly comes from a lack of will from the rest of an organization to not take steps to make things better, even when the writing is on the wall that they will have to sooner or later.
In short, yeah, it's kinda bad, but it's also not so bad. Something we all need to do, I think, is accept that what we were taught that coding would be like is fantastical. I guess I was influenced early on in such a way that I believed that one day the code would actually get better. With a handful of exceptions, it usually doesn't. Unless one is lucky, our job is to make it work and to figure it out when it's not working.
Another thought... At some point there's going to be a software caused disaster with very large human cost of life such that the governments of the world will demand and force regulation and certification. Software "Engineer" will have the same hoops and red tape every other engineering profession has to deal with and over the long run we may all be better off if it's not to late. If the transhumanists give birth to free willed laser-beams-for-eyes robot hybrids... probably too late. As dark as this sounds I hope a software disaster comes sooner than later.
The problem is that often management has been technical at some point in the past and will want a full breakdown of why something costs more time than they think to implement. Soon as you detail having to refactor X or do some other “non-essential” thing then it gets put on the cutting room floor.
I’ve experienced this a lot. It’s often people who have escaped having to write code that are the biggest backstabbers.
It's usually in the manager's best interest to deliver a feature faster even if it results in future features taking longer, because their bonus/promotion is dependent on delivering the current feature, not on the long-term impact.
I come from a culture of space-flight software where it needs to be right the first time or the mission fails. Good software is possible, it just costs more.
The crappier a codebase is the harder this becomes
Releasing without as much up-front costs lets you test more ideas. Getting your stuff space ready is a waste if your stuff doesn't actually have a market. There's a small margin of products where low initial quality kills the market, but mostly low initial quality is a pragmatic way to reduce cost of failure.
Sometimes it's a lot easier to do things the right way when the requirements are clear, and the best way to get clear requirements is to do it wrong and figure out why it was wrong.
Given that context, what do you mean by crap?
https://github.com/torvalds/linux
https://referencesource.microsoft.com/
https://github.com/redis/redis
I am sure there are lots of others.
Structure, testability, documentation and automation of the system give you a fighting chance.