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

351–360 of 704 posts

Re: Software engineering topics I changed my mind on

#351

Post by slx26 »

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.

People with experience are acknowledging this has value for newbies. That you already learned the lessons doesn't mean they aren't valuable to others. Sure, not the most exciting and creative piece of writing we have seen this year, but there's no need to be so dismissive either, we shouldn't let our own experience blind us.

Re: Software engineering topics I changed my mind on

#352

Post by toast0 »

l0b0 wrote: post #335

> People who stress over code style, linting rules, or other minutia are insane weirdos I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me…

I think this is a nuanced point.

Enforcing code style manually probably means not enforcing code style (at best, selective enforcement). But, I've yet to see a good tool that only enforces format on new/changed lines; and a reformat en masse is asking for trouble.

However, the arguments about a consistent style giving you benefits seems to fall flat when you've got dependencies that don't follow your style. If you're in go, and everyone uses gofmt, and always has, I guess that solves that. But you probably still have some code that's not in go (the OS you run on, at least), and that's probably not consistent. And if you're not in Go, you may have a different required style than your libraries and your language environment and nothing is consistent anyway; so why enforce anything beyond best effort blend in with the surrounding context?

Re: Software engineering topics I changed my mind on

#353

Post by potta_coffee »

captrb wrote: post #284
potta_coffee wrote: post #185

Earlier quoted context omitted.

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

Especially true when the services are all stateless. If there isn’t a conway-esque or scaling advantage to decoupling the deployment... don’t. I had a fevered dream the other night where it turned out that the bulk of AWS’s electricity consumption was just marshaling and unmarshalling JSON, for no benefit.

Exactly!

Re: Software engineering topics I changed my mind on

#354

Post by emteycz »

dragontamer wrote: post #313
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.

> 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. As someone who did sales early in my career... acting off of a script correctly feels like a casual conversation to the one you're selling to. If your script-reading is bad, that's because you haven't practiced enough. Having a script isn'…

Programmers are not salesmen, and this is not in their control, the scrum master often demands a question/answer type of conversation.

Re: Software engineering topics I changed my mind on

#355

Post by psyc »

aero142 wrote: post #149
hertzrat wrote: post #122

> People who stress over code style, linting rules, or other minutia are insane weirdos Really great post, although I do really value good, consistent code style. Readability really matters (imho). You can even use writing concepts like parallelism if you are feeling fancy to make things even easier to read.

I don't understand this claim of readability. If it were true, then you wouldn't be able to read a code base with a different code style. In truth, the switch takes about 10 seconds for me to get used to. Which is about 10,000 times less that the time I've wasted debating code style with other developers that insist that "consistency" is a useful goal without justification. There is exactly one concrete goal that I h…

I have no problem diving into a new code base on a new team with a style that’s unfamiliar. I absolutely do not want to switch styles as I work on the same project. I don’t much care what the style is. Successful implementations I’ve seen include: tasking one person to pick a style, then allowing exactly one meeting in which to iron out the quibbles. Or, literally googling for a style recommendation and just choosing one of the top results, as is, no discussion.

I agree that the endless religious arguments must be avoided. All the more reason to seek a strong manager and / or tech lead.

Re: Software engineering topics I changed my mind on

#356

Post by jayd16 »

tikhonj wrote: post #189
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…

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up . If something is important, why would you wait for tomorrow's standup? If something isn't important, w…

Better is better but a daily stand-up provides a common, catch all meeting with the entire team blocked off to participate.

Why wait? Well you could should tap(which we all hate), or you could email, ...or you could do something else in the mean time and bring it up in the daily.

Lets say you're blocked but don't know who to talk to? You could end up playing email tag or out on a few man hunts as you jump from team member to team member looking for who knows what ...or you could bring it up in the daily.

It solves a lot of problems, even if it doesn't solve every problem.

Re: Software engineering topics I changed my mind on

#357

Post by potta_coffee »

Joeri wrote: post #328
potta_coffee wrote: post #185

Earlier quoted context omitted.

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

The idea is that you can scale different parts of the system at different rates to deal with bottlenecks. With a monolith, you have to deploy more instances of the entire monolith to scale it, and that’s if the monolith even allows for that approach. If you take the high load parts and factor them out into a scalable microservice, you can leave the rest of the system alone while scaling only the bottlenecks. All of t…

I understand how microsercices work, but I'm referring to a specific kind of antipattern where an application is arbitrarily atomized into many small services in such a manner that there's zero scaling advantage. Imagine making every function in your application a service as an extreme example.

Re: Software engineering topics I changed my mind on

#358

Post by nielsbot »

rmk wrote: post #290
bawolff wrote: post #21

Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…

People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin t…

Opinion: but I think "invaluable" is overstating it. I agree with OP: not that important. Again, opinion. (20 years experience here)

Edit: I suppose I should clarify why. I think there are more important issues to focus on when building software with others.

Re: Software engineering topics I changed my mind on

#359

Post by projectileboy »

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’s a good question that every team should ask themselves rather than just blindly follow some scrum book. One reason that standups can be worthwhile is if your product managers are hard to get a hold of (which is common), it’s a guaranteed time when you can ask them some questions. But your mileage may vary.

Re: Software engineering topics I changed my mind on

#360

Post by [deleted] »

conanbatt wrote: post #192
ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

The engineers that believe they would thrive without managers are likely the ones managers exist for. It is simply absurd to believe that companies throw away billions down the tube for useless work.

[deleted]
Post reply on HN