Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Holding a Program in One's Head (2007)

paulgraham.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Holding a Program in One's Head (2007)

#101

Post by Too »

jll29 wrote: post #78
minkles wrote: post #42

Earlier quoted context omitted.

Those are called functions.

The UNIX way would be to break things down into actual programs, where each one would be doing one thing well - and in such a way that they'd be useful as building blocks for solving other problems also.

This must not be done prematurely. Replacing function calls with processes quickly break “go to definition” and all the other conveniences or guardrails provided by your compiler toolchain.

Unfortunately been dropped into that situation. The system was constantly broken due to missing of malformated arguments. Nobody dared to change anything.

Same applies to prematurely microservicing a monolith. At least there folks seem to be sensible enough to use protobufs or json, instead of loosely typed strings.

Re: Holding a Program in One's Head (2007)

#102

Post by Too »

jimbokun wrote: post #92
minkles wrote: post #86

Earlier quoted context omitted.

The unix way is re-parsing text 5000 times in separate programmes with no consistency or contract between them really. That's not great.

Only great enough to be the operating system for the vast majority of computing devices on the planet.

In close competition with the well renowned JavaScript.

Re: Holding a Program in One's Head (2007)

#103

Post by intelVISA »

tonyedgecombe wrote: post #99

>Probably the best we'll do is some kind of hack, like making the programming parts of an organization work differently from the rest. Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them. I remember the CTO of a big American bank telling me they didn't want to develop any software in-house. Their plan was to buy everything in. At the time I thought it wa…

>I remember the CTO of a big American bank telling me they didn't want to develop any software in-house. Their plan was to buy everything in. At the time I thought it was rather strange but having dealt with a lot of enterprise software since then I can see why.

It's a very pragmatic choice for the majority of business use cases. It should be more common imo, but some execs enjoy the empire building aspect and underestimate TCO when looking at cheap offshore dev resources.

Re: Holding a Program in One's Head (2007)

#104

Post by jimbokun »

tonyedgecombe wrote: post #97
jimbokun wrote: post #92

Earlier quoted context omitted.

Only great enough to be the operating system for the vast majority of computing devices on the planet.

The world is full of technologies that are ubiquitous but imperfect.

https://en.wikipedia.org/wiki/Worse_is_better

Re: Holding a Program in One's Head (2007)

#105

Post by ragnese »

kmoser wrote: post #12

"Use succinct languages" is somewhat at odds with "Write rereadable code." There's a point beyond which making your code more succinct makes it more difficult for a human to parse. This can be somewhat mitigated by comments but I'd rather just read more readable code than more succinct code.

Sure, but it's all so vacuously ambiguous that it doesn't really matter. I hate advice lists like this because it can essentially be summarized by saying "write good code" and you'd be left with almost exactly as much wisdom.

What does "succinct" mean? Well, it means terse but not too terse. What does "readable" mean? It means I can easily understand it.

How is this helpful?

Re: Holding a Program in One's Head (2007)

#106

Post by lubujackson »

tonyedgecombe wrote: post #95
FrankLicea wrote: post #93

How relevant is this when AI has the ability to both write and debug massive code bases? I imagine a future world where 100% of coding and debugging is done by prompt not by editing code.

If that comes to pass then I can foresee a world where code bases grow in size and complexity to the point of being barely maintainable. After all that's what we tend to do right now.

It's effectively no different than the shift from coding in assembly to using a compiler. We could abstract a level of complexity away, which should always be a positive. There will always be a level of human decision making because AI relies on human decisions and choices, so higher level architecting will be the new "scripting language" and we will all become the new neckbeards complaining how nobody know what's happening under the hood.

Re: Holding a Program in One's Head (2007)

#107

Post by wduquette »

sfn42 wrote: post #100
wduquette wrote: post #72

Earlier quoted context omitted.

When I’ve had to take over maintenance of code that isn’t mine, and is poorly commented and documented, which is usually the case, I work through the code and comment it. That eventually leads to refactoring, adding unit tests as needed, and so on…and eventually the code that wasn’t mine is now mine. But there’s no time in the schedule for that? Either that’s not true (the long way round is usually the shortest way h…

I do pretty much the same. If any part of the code makes me go "wtf" and sends me down a rabbit hole to figure out why it's like that, I'll typically write a comment about it to save myself and the next guy from that. However I have one quibble. Almost invariably when I explore other people's code, there's a lot of these "wtf" moments and some times they end with "oooh that makes sense" but honestly most of the time…

Ultimately you have two choices: you refactor the architecture as needed as part of implementing the current feature...or you end up drowning in technical debt farther down the line.

A properly architected code base makes it easy to make the kind of changes you want to make. A badly architected code base (as you describe) makes it nearly impossible. I've found it's usually by far the quickest thing to fix the architecture and then implement the new feature sanely. (And no, you don't ask permission; you just make everything clean. As I noted above, if your boss doesn't like this kind of thinking, you need a new boss.)

Of course, I'm one of those guys Graham mentions who works by himself most of the time.....YMMV.

Re: Holding a Program in One's Head (2007)

#108

Post by iamflimflam1 »

nickdrozd wrote: post #2

> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…

Nothing beats the experience of looking at code you wrote a year ago and thinking “who the hell wrote this nonsense”

Re: Holding a Program in One's Head (2007)

#109

Post by iamflimflam1 »

Reminds me of when I spent some time learning functional programming. I did a Scala course and I still remember solving some of the programming challenges. The slightest lapse in concentration - I would immediately lose understanding of what I was writing. It would turn from something amazingly simple and elegant into a thing that was incomprehensible.

Re: Holding a Program in One's Head (2007)

#110

Post by sfn42 »

wduquette wrote: post #107
sfn42 wrote: post #100

Earlier quoted context omitted.

I do pretty much the same. If any part of the code makes me go "wtf" and sends me down a rabbit hole to figure out why it's like that, I'll typically write a comment about it to save myself and the next guy from that. However I have one quibble. Almost invariably when I explore other people's code, there's a lot of these "wtf" moments and some times they end with "oooh that makes sense" but honestly most of the time…

Ultimately you have two choices: you refactor the architecture as needed as part of implementing the current feature...or you end up drowning in technical debt farther down the line. A properly architected code base makes it easy to make the kind of changes you want to make. A badly architected code base (as you describe) makes it nearly impossible. I've found it's usually by far the quickest thing to fix the archite…

Yeah, I completely agree with you. I might be a bit "scarred" by my previous team. We were working on CMS websites for a fairly large number of different clients. Every task was estimated by the hour, and if we went over that estimate it usually meant we were working for free. I mean I still got paid but my company didn't. It didn't help that all the solutions were either developed by Juniors or inherited from other departments/companies. Literally every moderately popular frontend tech was represented. React, Vue, AngularJS, jquery, nextjs, svelte, and more. Let's just.make our lives as difficult as possible eh, what should we use next? The back ends were all the same CMS luckily, but of course some genius had to go and add Sanity to the mix to pad their resume.

So I frequently had to learn a new js framework while dealing with shitty, unreviewed and untested code that barely worked or just kind of seemed to work, while under time pressure.

In that environment, my disdain for bad code really just didn't work out. Though I feel like I was a bit unfairly treated at times as well.

There was this one app that had an integration against a third party API. They had used a library to interact with the API, this library was purchased for a fairly significant amount of money from some university and it was complete garbage. All it did was get data twice a day and store it in a db, then the CMS had a daily scheduled job that would get the data from that db and build the content in the actual CMS db. It was like 30k loc, a lot of which was dead and the rest of it was shitty and redundant manual xml parsing and completely unnecessary db interaction. Not to mention the (probably minor) cost of running this pointless db.

So there's a problem with it and I spend days bughunting, I can't figure out what's wrong. I try telling the team that I think I can build a better solution from scratch faster than I can fix this bug. No bueno. So over the weekend, on my own time, (really just a few hours) I throw together a quick POC. I don't need the intermediate DB, the CMS can just get the data from the API once a day during the scheduled job. So 90% of the work is just making DTOs to deserialize the xml into, using whatever xml serialization library i found.

I finish it, hook it up, it's not totally done but it pretty much works already. On Monday I tell the team what I've done and just get completely shut down. They don't even want to see it, just nope.

So that code is gone and they're still maintaining that piece of shit library for no reason. Oh well, luckily it's not my problem any more.

Sorry about the rant, and thanks for the support. It's nice to know I'm not alone in seeing the value of quality.

Post reply on HN