It was a great write up in its time but has since become a goto cliche for people who can't write much code.
Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!"
Barba non facit philosophum: a beard doesn't make one a philosopher.
191–200 of 222 posts
It was a great write up in its time but has since become a goto cliche for people who can't write much code.
Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!"
Barba non facit philosophum: a beard doesn't make one a philosopher.
Earlier quoted context omitted.
And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics). Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as. LLM's and especially online song choice algorithms have a heavy dose…
Where does Uncle Bob fit into this? Because he sure does love to give advice How small a function should be? https://youtu.be/rXjf8eiGsSI
Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?
I never understood why is it when people talk about LoC of code written, they always use 'lines added - lines removed'. If I do a run 10km run and end up in the same place I started, it's not a 0km run.
if cond { ... return; } ...
into
if cond { ... return; } else { .... }
But that's not comprehensive either.
The real story here is that sometimes you start a project and don't really know exactly where you're going, as you get into it you start to understand both the problem and the answer you want much better - and then yes, you can rip a chunk out and replace it with something smaller and better And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM -…
QuickDraw is mostly written in Pascal with critical loops in assembly[1,2]. I’m also not sure if it’s in actually in ROM or on the boot floppy. (Incidentally, Wikipedia tells me the Lisa’s ROM was 16K.) [1] https://computerhistory.org/blog/the-lisa-apples-most-influe... [2] https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
Earlier quoted context omitted.
QuickDraw is mostly written in Pascal with critical loops in assembly[1,2]. I’m also not sure if it’s in actually in ROM or on the boot floppy. (Incidentally, Wikipedia tells me the Lisa’s ROM was 16K.) [1] https://computerhistory.org/blog/the-lisa-apples-most-influe... [2] https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk If you follow that second link you'll find a zip file with quickdraw source in it, you'll…
Earlier quoted context omitted.
Here's some counterexamples to that idea: - a bugfix which takes ages to find and ends up being one or two lines of locally trivial code - a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code - overzealous code formatters: lots of lines of code - a junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly…
> There is 0 correlation, none whatsoever This is quite unlikely to be true. No correlation at all? Especially if we shift to ΔSLOC rather than +SLOC, I don't believe that for a second. You've made a good case that it's a bad proxy for productivity. It is. But there's no need to over-egg the pudding.
Earlier quoted context omitted.
Here's some counterexamples to that idea: - a bugfix which takes ages to find and ends up being one or two lines of locally trivial code - a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code - overzealous code formatters: lots of lines of code - a junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly…
> a bugfix which takes ages to find and ends up being one or two lines of locally trivial code I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're im…
> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
> The old days of a software as an artisanal craft is long over imho. In corporate or government software work, sure. But there are no guilds anywhere in those organizations... unless you count the upper executives. You might not get paid for it, but the artisanal craft of software is alive and well in free and open source software around the world. Tons of those projects get posted to HN. An app can be a home cooked…
aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it.
> if it is your startup, you can write code however you want.
yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.
> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
For better and for worse, it's been decades since filling out a form was a necessary or even useful part of tracking this sort of thing. The widespread use of revision control and ticketing systems means that management has that data at their fingertips whenever they want it. Sometimes that's good, sometimes it isn't. But I think we can count relieving the developers of the drudgery of form-filling as an unalloyed go…
The point is that there are management styles out there that tries to objectively measure a software engineer's performance (poorly). And unless you are someone with high clout in the organization, you are subjected to it regardless of whether you like it, it making sense, or it being used to control the employees (politics).
Early in my career I once optimized an inherited 10,000+ line C program to less than 500 lines. It was a C program making SQL calls into a Sybase database. No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline wi…