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

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

361–370 of 704 posts

Re: Software engineering topics I changed my mind on

#361

Post by toast0 »

baccheion wrote: post #25

I dislike sacrificing purity, but I am capable of doing it. Most software is a hogpile of sh*t destined to rot. It simply won't last. Those sections that do (if it never has to be touched, it also didn't last) are usually subpar. Especially with accumulating "ship ship ship" modes, costs, and competing via speed, it'll only get worse. Most time spent cleaning up code and improving architecture is time wasted. The sta…

> Most software is a hogpile of sh*t destined to rot. It simply won't last. Those sections that do (if it never has to be touched, it also didn't last) are usually subpar.

Look, most of my code is shit. I expect the requirements to change sometime in the next two weeks. The code isn't expected to rot, it's expected to be thrown away.

Anything that sticks around longer than that isn't subpar, it managed to actually meet the underlying requirements.

Anyway, if my shitty code ends up becoming a problem later; I don't have any qualms about sunk costs, because I didn't build a pinacle of architecture; and I'll probably have a much better idea of what the requirements and use-cases are.

Mostly, the important thing is to reduce the amount of layers. It's a lot easier to make changes to shitty code without too many layers than polished code that has wrong or inconvenient abstractions. Of course, shitty code that's over abstracted is even worse.

Re: Software engineering topics I changed my mind on

#362

Post by eyelidlessness »

pseudalopex wrote: post #202
eyelidlessness wrote: post #187

Earlier quoted context omitted.

Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They should…

It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.

You’re right it shouldn’t. Those don’t need a recall election. Just a normal one. Elections should be like sprints too.

Re: Software engineering topics I changed my mind on

#363

Post by ozim »

hordeallergy wrote: post #318
projectileboy wrote: post #299

Earlier quoted context omitted.

In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.

Why not just have casual conversations instead? Standups are one those things that people disagree on endlessly without discussing context - their worth depends on the team. On my current team they're worthless. I'd rather have casual conversation, but that's like squeezing blood from a stone. Departure planning underway.

It should be, but not everyone on the team has to be confident. Not everyone has to be outspoken, not everyone has to have perfect pronunciation. Not everyone is able to structure their thoughts in 1 minute, even though they are able to work on complex systems.

What you want from "what you did yesterday, blockers, what you will do today" script is a framework for conversation starter, conversation scope and having something that you can prepare before. Some people can come up with it on the spot and some people think they should come up with it on the spot.

That is why I hate having standup right at the start of the day like 9.00, I usually have to get at least 20 mins to get check up what I finished yesterday and start picking up something new, going through priorities.

Re: Software engineering topics I changed my mind on

#364

Post by username90 »

njharman wrote: post #319
xmprt wrote: post #293

Earlier quoted context omitted.

Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function. The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

Faster code is not fine. Faster code should only be written after finished product is shown to be too slow for purpose and after profiler has shown which parts of code are worth optimizing.

You should always have a good idea of what part of the codebase will be the bottleneck when you write it. If you have that just optimize the things it spends time on. The only time you really need a profiler before optimizing is when you are micro optimizing to try to handle cpu ordering etc, other than that performance is mostly predictable.

Re: Software engineering topics I changed my mind on

#365

Post by meheleventyone »

njharman wrote: post #319
xmprt wrote: post #293

Earlier quoted context omitted.

Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function. The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

Faster code is not fine. Faster code should only be written after finished product is shown to be too slow for purpose and after profiler has shown which parts of code are worth optimizing.

This can be too late for the product though. If you have real performance requirements for example you’re making a game and it needs to render at 60Hz optimising at the end can be an impossible task. This is also further complicated when data dependencies also impact performance. For example level designers need some understanding of the complexity of the scenes the game will be able to support.

Re: Software engineering topics I changed my mind on

#366

Post by cryptica »

It sounds like were I was around my 5th year of coding. After 15 years though I changed my mind again on certain things.

> Typed languages are better when you're working on a team of people with various experience levels

I've changed my mind back and forth multiple times about statically versus dynamically typed languages and after 10 years I settled on dynamically typed languages as superior in almost all cases. The main case where statically typed is better is if most people on your team are juniors and you are doomed to produce poor quality code so in this case you might as well 'label the spaghetti'...

I can say with almost 100% confidence that sticking to dynamically typed languages leads to worse quality in the long run. It has to do with loss of separation of concerns and subtleties of human psychology (gives false confidence, leading to neglect, encourages over-engineered interfaces which creates tight coupling between components and thus ossifies design mistakes and makes them less interchangeable and interoperable with other systems).

> Software architecture probably matters more than anything else.

This is the most important thing. 100% true. Glad the author seems to really get this. Some people don't figure this out after 20 years.

> Designing scalable systems when you don't need to makes you a bad engineer.

I disagree about this point. Writing scalable code can be elegant and fast development wise and performance wise. It just requires more careful design to get right. A bad or even 'mid level' engineer will over-engineer it; that's the real problem.

A bigger problem is when engineers create too many unnecessary abstractions and that doesn't scale in any way. In many cases, scalability requires very few abstractions in order to work. It requires very elegant code.

Re: Software engineering topics I changed my mind on

#368

Post by js8 »

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

> If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!"

I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so that everybody knows about him being an expert and consults with him on a regular basis.

Is it really better to have everybody a shallow experience with everything rather than have a few individuals with a deep expertise with a particular thing?

And to have a meeting every day to "solve" this non-problem (somebody not knowing who the expert is, or supposed to be) seems really inefficient.

Re: Software engineering topics I changed my mind on

#369

Post by tgv »

illustriousbear wrote: post #297

Another low effort blog post that Hackernews readers have upvoted because it says obvious things that they agree with. Quality on blog posts and articles is taking a bit of a dip lately.

It's just a list, no arguments, so that's not high quality, indeed. But the author speaks from experience, and it resonates with experiences from others here, mine included (although I'm using a nosql db for recent projects). It offers a starting point for some discussion and elaboration, so it's fine by me.

Re: Software engineering topics I changed my mind on

#370

Post by eecc »

One thing that bothers me and is only tangentially mentioned is code formatting. I don’t have particular favorites but I do appreciate consistency but most importantly: when introducing or changing a formatting rule apply it to all the project in 1 commit. Never, ever dare to apply it “as-you-go” when implementing changes and touching existing files. Makes reviewing a nightmare
Post reply on HN