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

111–120 of 704 posts

Re: Software engineering topics I changed my mind on

#111

Post by gpanders »

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.

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 colleagues’ code.

Re: Software engineering topics I changed my mind on

#112

Post by kazamaloo »

01100011 wrote: post #81
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…

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in…

We used to have 3 PMs in our team of 20ish people. Two of the PMs left and NOTHING changed for us or our project.

The idea of being relieved of process-related tasks is nice, but it rarely happens. You get pulled in to those timewasting meetings by your PM anyway.

Re: Software engineering topics I changed my mind on

#114

Post by bawolff »

01100011 wrote: post #81
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…

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in…

I feel like a good PM is someone who makes sure everyone is on the same page and working towards the same goal. If they are good at their job, you dont notice them.

Otoh If they are bad at their job, they really get in the way, cause a lot of resentment and extra busy work.

The end result is selection bias - lots of engineers think they are useless because you only really notice the useless ones.

Re: Software engineering topics I changed my mind on

#115

Post by dnautics »

Here's what i have to say about TDD (I do not practice TDD on a day-to-day basis).

Even if you don't use it, you should know what it is. If you choose to use it religiously, that's probably a bad choice, but if you don't do it ever, you are missing out on a huge tool. In general, if I see an insurmountably complex challenge ahead of myself, sometimes TDD (especially detroit-style TDD) is a tool to refocus my attention and implement the minimal implementation and move past goals.

Also, doing test-heavy development (which TDD gives you for free) gives you insight into how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort.

Re: Software engineering topics I changed my mind on

#116

Post by BeetleB »

joseph_grobbles wrote: post #94
silentsea90 wrote: post #68

Earlier quoted context omitted.

10 minutes is hardly an investment in both ensuring devs share a goal they're committed to at the start of the day, and that devs aren't going down the wrong path, and people are in sync. I have had many standups where days of person X's time was saved by person Y offering a suggestion on how to do a certain task. Don't let a standup go beyond 10 minutes. X and Y in the above example should sync after the standup sep…

"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 people were on vacation and some were late. When the late people showed up, it would be to an empty room. We didn't wait for them beyond 1 minute.

There's no way we would tolerate 30 minutes, let alone an hour. If it was going beyond 15 minutes, many/most of the developers would abruptly leave. You have to have an idea what you're going to say before you enter the room, and not go into technical details - the standup is not a problem solving session. People who randomly droned in giving their update would be "coached".

For a while we had the manager in the room. Then we booted him out - he was no longer welcome (it was an amicable parting :-) ).

> but what I just described is the standup reality virtually everywhere.

I can believe your experience is more common than mine, but I can also say I wouldn't work with such sloppiness in the team. In our case, our team wasn't the standout. This discipline was drilled in at the organizational level and had support from the leaders.

It may sound bad the way I write it, but it was actually very easy to cultivate this culture, and everyone liked it. This was literally the easiest and simplest part of the work day.

Edit: Lest this come off as a pro-scrum comment, I assure you it's not. There are things I don't like about Scrum, and am not sure I'd like to go back to working scrum-style. However, the complaints in the parent post are not problems with scrum, but cultural problems. As one of the pro-scrum people in my company put it: "I'm not really sure Scrum does a great job in improving productivity. But it's excellent at exposing existing problems in teams."

Re: Software engineering topics I changed my mind on

#117

Post by joseph_grobbles »

Rapzid wrote: post #109
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…

> virtually everywhere I've never experienced that in the 7-8 companies I've worked at over the past 10 years.

At the last 7-8 companies I've worked at, I've described exactly how it has been. I have been personally responsible for eliminating them at the last 4 orgs. They were an echo of shitty management.

And I'm hardly alone in observing this being a common pattern.

Re: Software engineering topics I changed my mind on

#118

Post by username90 »

silentsea90 wrote: post #68
throwawayboise wrote: post #53

Coming up on 30 years. I agree with most of your observations except standups. In my experience daily standups are a waste of time. Maybe I've just had bad luck with them?

10 minutes is hardly an investment in both ensuring devs share a goal they're committed to at the start of the day, and that devs aren't going down the wrong path, and people are in sync. I have had many standups where days of person X's time was saved by person Y offering a suggestion on how to do a certain task. Don't let a standup go beyond 10 minutes. X and Y in the above example should sync after the standup sep…

Standups makes sense if people work close together on a fast moving project. They don't make sense for people who work on unrelated things or projects that move slowly. Then they just become a "who did the most last day?" bragging session since nobody has any use of the information of what others did that is all it can be used for, and when that happens all it achieves is hurting team morale.

Re: Software engineering topics I changed my mind on

#119

Post by jackcosgrove »

BobbyJo wrote: post #98
jackcosgrove wrote: post #86

Earlier quoted context omitted.

You can hedge by breaking up your codebase into logical services from the start which own their data sources and controllers. When the time comes to break up into microservices, you separate each service into its own application rather than grouping them in a monolith.

Writing services in a separable manner is, in a sense, writing scalable software.

Write the microservice, deploy the monolith. You can save on hosting costs. It's not perfect, no.

Re: Software engineering topics I changed my mind on

#120

Post by gryn »

throwawayboise wrote: post #53

Coming up on 30 years. I agree with most of your observations except standups. In my experience daily standups are a waste of time. Maybe I've just had bad luck with them?

agree, what I found useful although I kinda hated at first, was slack messages at the end of the day where I was asked what I did for the day (sometimes followed by what I'll be doing for the next). this includes blockers and other related aspects, like wether I need some aditional manpower for the task at hand.

it was in private messages so it avoided wasting other people's time or distracting them.

Post reply on HN