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

61–70 of 704 posts

Re: Software engineering topics I changed my mind on

#61

Post by ng12 »

> 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 them have it.

A big part of the problem in my experience is that PMs tend to proliferate. I've seen many startups go from hiring their first "product" person to suddenly having a PM team that's a third the size of engineering.

Re: Software engineering topics I changed my mind on

#63

Post by gryn »

dimtempo84 wrote: post #2

I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.

On the other side, at my current place of work, there's one person that throws a fit every time someone is not following the linting rules, the CI/CD rejects anything, mostly trailing trailing spaces. What drives me nuts is not the fact that he's obsessed with them, but that he actually put no thought whatsoever into what rules to apply, he just put the first one he found on the internet, and is regiouly following them and forcing them on the rest of us.

Re: Software engineering topics I changed my mind on

#64

Post by pdimitar »

> Functional programming is another tool, not a panacea.

That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction.

Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy with 19 years of experience I seriously wish I could forget some of the codebases I had to inspect.

So while FP is just another tool, it's also a framework for thinking that helps people make better choices. Same goes for static strong typing.

Re: Software engineering topics I changed my mind on

#65

Post by virmundi »

cbdumas wrote: post #38
virmundi wrote: post #15

Earlier quoted context omitted.

Are there other constraints that might make DynamoDB a good fit? For example I made an app at a client. We could use RDS or we could use Dynamo. I went with Dynamo because it could fit our simple model. What’s more, it doesn’t get shut off nightly when the RDS systems do to save money. This means we can work work on it when people have to time shift due to events in the life like having to pick up the kids.

I can't speak to your specific use case, but I can tell you that a relatively small RDS instance is probably a lot more performant than you think. There is also "Aurora Serverless" now which I've just started to play with but might suit your needs. As far as what makes Dynamo a good fit, I almost take the other approach and try to ask myself, what makes Postgres a bad fit? Postgres is so flexible and powerful that IM…

Aurora wasn’t allowed at the time. The system is a simple stream logging app. Wonderful for our use case. Dynamo for so far. Corp politics made the RDS instance annoying to pursue.

Re: Software engineering topics I changed my mind on

#66

Post by BobbyJo »

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.

Re: Software engineering topics I changed my mind on

#67

Post by sk5t »

gameswithgo wrote: post #46

>Java isn't that terrible of a language. That is going to evolve in the next six years to "languages don't usually matter much except in specific domains in a few cases"

Except when you care about the ecosystem, build tools, willingness of the rest of the team to maintain the codebase, etc.--so the language usually matters even if you're not religiously dedicated to one in particular.

Re: Software engineering topics I changed my mind on

#68

Post by silentsea90 »

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 separately in case their discussion is longer than the duration of the standup

Re: Software engineering topics I changed my mind on

#69

Post by Igelau »

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?

The problems creep in if they get too big. Too many people and it's a huge waste of time. If non devs are sneaking in, they shouldn't be permitted to speak.

Re: Software engineering topics I changed my mind on

#70

Post by the_cat_kittles »

naikrovek wrote: post #48

> So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot That's the truth. "Best Practices" often force you to ignore what your problem actually is and view it in some twisted way that fits the practice. Bad. Your problem is your problem. Your data is your data. Write code that matches what you have and what you're trying to do.

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)
Post reply on HN