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

131–140 of 704 posts

Re: Software engineering topics I changed my mind on

#131

Post by SAI_Peregrinus »

gpanders wrote: post #111
d3nj4l wrote: post #72

Earlier quoted context omitted.

Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.

Agreed with you and the GP. In one project I’m on, I pushed for linting and formatting checks in our CI not because I’m an “insane weirdo” who cares too much about formatting, but precisely because I don’t care, I just want it to be consistent. I don’t really have an opinion about which style or format or whatever is better, I just don’t want to have to read through 6 different coding styles when I scan through my co…

Having a consistent style enforced by an automatic tool set (linter/autoformatter/etc) means no time needs to be wasted in any given PR arguing about style, or waiting for someone to fix a style mistake. You might still waste time arguing about what the rules should be, but that's often less than the cumulative waste of fixing avoidable crap.

Re: Software engineering topics I changed my mind on

#132

Post by nitrogen »

blabitty wrote: post #51
PragmaticPulp wrote: post #41

Earlier quoted context omitted.

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

I like to half jokingly assert that microservices are a pysop to sell cloud hosting

If I were an evil tech giant, I would open source a bunch of libraries that require significantly more effort to use than necessary, and pitch them as the One True Solution. Just to slow my competitors down.

Re: Software engineering topics I changed my mind on

#133

Post by dathinab »

naikrovek wrote: post #102
the_cat_kittles wrote: post #70

Earlier quoted context omitted.

i basically have 1 meta best practice, which is- everything you make should work 100% of the time (not that i live up to this)

Mine is that "this should never waste a user's time unless absolutely necessary." And it is absolutely shocking how many developers do not care if they make a user wait a minute for something that should take To me, it is a moral failing if my laziness costs user's time. Remember how many users you have and multiply delays by the number of users delayed by your code.

Yes but also don't overoptimize it's normally not worth it at all.

The relevant decisions are often about the UI/UX design and flow as well as the architecture, but less about optimizing code sections here and there.

Re: Software engineering topics I changed my mind on

#134

Post by username90 »

woeirua wrote: post #62

The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.

Obsessing about scaling is what makes this industry. How else would we keep up software engineering demand?

Re: Software engineering topics I changed my mind on

#135

Post by surprisetalk »

danfang wrote: post #113

I agree with most of the points the author makes. > Pencil and paper are the best programming tools and vastly under used I'm not convinced of this one. I grew up with digital tools only. Can someone give me examples where this assertion is true?

In my experience, pen-and-paper helps me resist the urge to “just get started already”.

I don’t know why, but when I’m in the design-phase with a keyboard in my hands, I think I get too excited about building things and go straight to the text-editor to “hammer out the details” in code.

Away from the computer, I’m much more likely to complete a thorough design. And pen-and-paper remains my favorite tool for working on ideas that are too big to fit in working-memory.

Re: Software engineering topics I changed my mind on

#136

Post by RcouF1uZ4gsC »

d3nj4l wrote: post #72
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,…

Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.

The solution to this is to use an automated formatting tool for the entire team and have it automatically run prior to review and be done with it.

Re: Software engineering topics I changed my mind on

#137

Post by crdrost »

jimbob45 wrote: post #105
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…

Agreed. It’s a deliberate inefficiency to make sure you at least have a chance to communicate with your team on a regular basis. Otherwise you might go days or weeks without the chance to have a critical two minute conversation.

That sounds suspiciously like your team is not communicating enough in the first place though. I mean, I guess the profession does get its fair share of introverts, but I would have expected enough teamwork that everyone knows what everyone else is doing, at least roughly. At my last gig I remember we had three backenders and four frontenders on a game we were building and the stand-ups seemed superfluous, Ryan on the frontend knew all of the frontend tasks and their exact states, I on the backend knew all of the backend tasks and all of their states, stand-ups were more of a means to celebrate what folks had done and coordinate that info with our QA team.

My silver rule of meetings is “to make a meeting matter, make a decision.” If we were assigning new tickets and/or backlog, deciding who would own each of them, that meeting is valuable. Progress updates can be delivered asynchronously and consumed asynchronously, unless, say, one wants group applause.

Of course now covid exists and I changed jobs to a team that barely talks with me and daily stand-ups are kind of my only social contact with them, so that's less fun. But yeah, 100% the original vision of agile with the “developers should be meeting daily with the product users to clarify the underlying model and mold the software to their hands” should cause people to work together so much that stand-ups become something of an afterthought.

Re: Software engineering topics I changed my mind on

#138

Post by joseph_grobbles »

BeetleB wrote: post #116
joseph_grobbles wrote: post #94

Earlier quoted context omitted.

"10 minutes" Are you the only one attending or something? Standups are initially scheduled for the start of the development day. But then people come in a little late, get that first minute call, have to attend to something that hiccupped, so soon enough the standup happens 30 minutes into the day, eventually an hour into the day. So if you did get there on time, now you just spin your wheel waiting, because first yo…

In the one job where standups went well, our limit was 15 minutes, for about 7 developers. > Standups are initially scheduled for the start of the development day. There's no reason it should. We did not have it at that time. If it's at a reasonable time (e.g. after all people have normally begun work), then have a low tolerance policy for those who come late. Sometimes our standups were about 5 minutes, because some…

If you don't have it at the beginning of the day, then you're putting a hard gate on flow. This phenomena is well known, and the disruption of having a scheduled event mid-workday is significantly larger than the time of the disruption. Everyone is going to fade out of their work long before and won't re-engage for sometimes after.

As to scrum exposing cultural problems, maybe that's true, but in some cases scrums are a clumsy attempt to solve cultural problems (as I said in another comment, agile was the failure mode for orgs stumbling with "waterfall").

Terrible progress visibility? Let's have a scrum! No team member communications? Scrum will fix it! People sandbagging or not doing their work? Don't worry, Scrum will save the day!

On good teams we all know what each other is working on. We're all aware of the codebase. We see the commits. We are available when someone has a problem (and people know who is a good person to asynchronously ping when they have a problem in specific domains), and are open to the reality that everyone is imperfect and doesn't know everything. On good teams scrums serve absolutely no value, and are a redundant waste of time. On bad teams they are an attempt to bandage over all of the lack of those factors.

Re: Software engineering topics I changed my mind on

#139

Post by axaxs »

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…

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

Re: Software engineering topics I changed my mind on

#140

Post by Aeolun »

PragmaticPulp wrote: post #41
cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume

Then they are bad engineers. It is true that it’s best for their resume, but I also have my professional integrity to maintain.

Post reply on HN