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

91–100 of 704 posts

Re: Software engineering topics I changed my mind on

#91

Post by ng12 »

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…

If you're hiring more people to deal with rote, managerial "process" you're already lost in a mire of inefficiency.

Re: Software engineering topics I changed my mind on

#94

Post by joseph_grobbles »

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…

"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 you've got that obnoxious standup that's going to disrupt everything.

Now you get there and spend ten minutes waiting for everyone to assemble, and for the S.C.R.U.M.Master to pull Jira up on the overhead. Finally you get going and everyone has an essay about their herculean effort putting a button on a form, which absolutely no one is listening to. You have the manager (because really they're a garbage way of managing) interjecting and asking questions. You have someone say something dumb they're doing and everyone gets to stand there while two people who could have taken it offline have a conversation.

40 minutes later you go back to your desk.

Invariably the standup aficionados (almost universally shitty managers) will say "you're doing it wrong!", but what I just described is the standup reality virtually everywhere.

EDIT: Exactly as expected, I made the mistake of actually replying to people who questioned my comment, which means when some angry person comes along they get to downvote all of them. That aspect of HN is weak sauce.

Re: Software engineering topics I changed my mind on

#97

Post by baron816 »

I think this makes for an EXCELLENT interview question.

Engineers with strong opinions are better than engineers who just do whatever others want and haven't thought deeply about anything.

But even better is an engineer whose opinion changes as more information becomes available.

You want to hire the person that is capable of both making a thorough case for one approach, and is mature enough to admit that that approach is suboptimal and then go implement the optimal one.

Re: Software engineering topics I changed my mind on

#98

Post by BobbyJo »

jackcosgrove wrote: post #86
BobbyJo wrote: post #66

11 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.

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.

Re: Software engineering topics I changed my mind on

#99

Post by [deleted] »

d23 wrote: post #75
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…

Eh, the second one is probably the only point I was kind of meh on. You should almost always start with an RDBMS, and it will scale for most companies for a long long time, but for some workloads or levels of scale you're probably going to need to at least augment it with another storage system.

[deleted]

Re: Software engineering topics I changed my mind on

#100

Post by Rapzid »

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.

I believe though that you should just have some system in place to automatically check/fix these issues(for the most part). I've been in far too many environments though where PR reviews are just surface-level formatting nits and don't address functionality or architecture at all..
Post reply on HN