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

Code doesn’t have to be a mess

danielsieger.com

Post reply on HN
Print view View original

71–80 of 190 posts

Re: Code doesn’t have to be a mess

#71

Post by camgunz »

Cerium wrote: post #57
camgunz wrote: post #51

Earlier quoted context omitted.

I'm not a junior dev and I still get peeved when my time is wasted. I guess I would only not care if I didn't care about what I was working on, but that's a different kind of existential torment haha. Beyond opportunity cost, you can think of it as deleterious to your performance. If 10% of your work never gets merged because of shifting priorities, compared with someone else who has miraculously dodged these problem…

Try to direct your personal energy away from getting your code into the product and towards making the best product possible. Often after building a feature it is obvious that it makes the product worse. I've had many such features cut.

My irritation comes from that decision/realization happening after we already devoted engineering time to something--the most expensive time to reverse yourself.

Re: Code doesn’t have to be a mess

#72

Post by pflenker »

klibertp wrote: post #64
camgunz wrote: post #51

Earlier quoted context omitted.

I'm not a junior dev and I still get peeved when my time is wasted. I guess I would only not care if I didn't care about what I was working on, but that's a different kind of existential torment haha. Beyond opportunity cost, you can think of it as deleterious to your performance. If 10% of your work never gets merged because of shifting priorities, compared with someone else who has miraculously dodged these problem…

> that's pretty unfair. Hilarious. I wonder what a plumber or carpenter would say if you were to complain to them on how unfair your job is, because 10% of your output doesn't show in the finished product, yet you are still paid for that output. Imagining the reaction to that just made my day.

Plumbers and carpenters find purpose in what they do, and so do engineers. Getting paid is just one factor of several for job satisfaction.

Re: Code doesn’t have to be a mess

#73

Post by nicoburns »

hinkley wrote: post #45
samsquire wrote: post #33

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

Maybe I'm weird but a lot of my refactoring actually concretizes overly abstract code. It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to…

> It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things.

This is why Sum Types are so great. They give you an option between "concrete type" and "any type that implements this interface": "one of these specially enumerated types".

Re: Code doesn’t have to be a mess

#74

Post by angarg12 »

donatj wrote: post #26

> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.

I believe many companies also incentivize this. Not many people get praise, raises and promos by saying no or simplifying things, much less juniors. Once you've built something and put it in your promo doc, no one wants to remove it or say it was the wrong thing to build.

As an example, I did an spike to explore a request from another team. I wrote a short document with my findings and recommended against it due to the cost/benefit analysis. My manager told me not to use this story in my performance review since "we don't want to display failures".

Re: Code doesn’t have to be a mess

#75

Post by wefarrell »

Personally I think the most important thing to minimizing code complexity is ensuring that it understandably maps to the business logic. The business logic is the essential complexity and everything else can be seen as waste.

The first step is getting the lexicon right. Frequently the business lexicon is ambiguous in such a pervasive way that the people immersed in the business aren't aware of the discrepancies. For example I remember from working in healthcare the words "claim" and "member" often have very different meanings in different contexts and I would see developers hacking code together to get the data model of one context conform to the data model of another when they should have been treated as different entities.

Re: Code doesn’t have to be a mess

#76

Post by samsquire »

awild wrote: post #39
samsquire wrote: post #33

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

I try to encourage newcomers to refractor the code into a form they understand, fix the problem and then undo that refactoring as much as possible. If they actually come up with a better abstraction I'm up for it. Refactoring will give them the chance to see what the actually moving parts of code are.

I like your use of the words moving parts. Eventually code ends up looping over memory locations, copies, moves, adds, subtracts, multiplies, divides, reads, writes data or memory locations.

All the files and code on the way to get this to happen such as Classes, parameters, arguments, variables, functions, methods, closures, objects are ideas of the languages compiler to abstract the instruction stream.

Command line arguments, class constructors, URL query parameters, marshalling, JSON field names, method parameters, function arguments, HTTP headers, cookies, request objects, events are just complicated variations of passing data in the right shape. They are not the above list of "moving parts" or computation that is easy. In other words modern coding is just configuration.

I feel the complexity of modern code is a problem we created. And I feel there's something missing. It's hard to update code.

When I find the loop that does the thing, I feel I can understand the codebase such as the magic +1, -1 or the relationship of objects linked together in a data structure or the assignment to a list or array or variable.

"How does that get to here"

Re: Code doesn’t have to be a mess

#77

Post by viktorcode »

> If you’ve been developing software for a while, you know that code has this natural tendency to turn into a mess.

That doesn't apply to everyone and every project. When people leading the project are experienced developers understanding clean architecture the mess is just an oversight which is local and can easily be corrected.

Re: Code doesn’t have to be a mess

#79

Post by corrral »

camgunz wrote: post #51
korijn wrote: post #41

Earlier quoted context omitted.

Being married to your code/output is just another flaw typical for juniors. Put them on features that aren't critical or ensure they are made aware up front that their work may be rejected if it doesn't meet design expectations.

I'm not a junior dev and I still get peeved when my time is wasted. I guess I would only not care if I didn't care about what I was working on, but that's a different kind of existential torment haha. Beyond opportunity cost, you can think of it as deleterious to your performance. If 10% of your work never gets merged because of shifting priorities, compared with someone else who has miraculously dodged these problem…

10%? Holy shit, I'd say a solid 90% of my output never brought enough value to justify doing it in the first place. Much of it without ever seeing a real user. Software development feels like digging holes and filling them back up again, over and over, to me.

Re: Code doesn’t have to be a mess

#80

Post by the_other »

hinkley wrote: post #45
samsquire wrote: post #33

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

Maybe I'm weird but a lot of my refactoring actually concretizes overly abstract code. It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to…

I had to look up "telegraph" to confirm I'd understood you correctly. I don't recall seeing it used in the context of describing language, so I doubted my interpretation. I've heard it used most in discussions of boxing: a boxer's posture or their sequence of muscle activations _telegraph_ their planned attack such that their opponent has time to block or counter.

I like the way you used it. I'll try to use that myself.

Post reply on HN