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

41–50 of 704 posts

Re: Software engineering topics I changed my mind on

#41

Post by PragmaticPulp »

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 trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. It doesn’t help that some companies screen out resumes that don’t have the right signals (Microservices, ReactJS, NoSQL, ...). There’s a certain amount of FOMO that makes early-career engineers feel like they won’t be able to move up unless they can find a way to use the most advanced and complex architectures, even if their problems don’t warrant those solutions.

Re: Software engineering topics I changed my mind on

#42

Post by cbdumas »

bawolff wrote: post #26
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…

People always talk about nosql scaling better, but some of the largest websites on the internet are mysql based. I'm sure some people have problems where nosql is genuinely an appropriate solution, but i find it hard to believe that most people get anywhere near that level of scalability.

Exactly, and from a features standpoint Postgres can do everything Dynamo can do and so much more. I think a lot of software devs don't really know SQL or how RDBMS work so they don't know what they are giving up.

Re: Software engineering topics I changed my mind on

#43

Post by brightball »

the_cat_kittles wrote: post #24

wise to avoid an opinion on ORMs, otherwise this would devolve rapidly. my opinion is they are potentially useful but i have never worked a job where id rather have an orm

I like them when they simplify repetitive things, require minimal configuration and are easy to get out of your way when you and the database need to have a grown up conversation.

Re: Software engineering topics I changed my mind on

#44

Post by baby »

> YAGNI, SOLID, DRY. In that order.

What?

> Java isn't that terrible of a language.

Doesn’t mean it’s a good language though.

> Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers

And when people ask for numbers, it is usually because they don’t like your idea

> People who stress over code style, linting rules, or other minutia are insane weirdos

That’s why you need languages with good defaults for formatting and linting (e.g. Go, rust)

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.

I admit I still don’t understand what a PM really does.

Re: Software engineering topics I changed my mind on

#45

Post by yongjik »

alain_gilbert wrote: post #11
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.

I used to be an "insane weirdo", but at some point I gave up. Now, I just focus on code correctness, merge and fix the code style myself, avoiding a lot of useless back and forth. My hope is that people like to see their name when they "git blame" (what's the PC version of "blame" again?) So they will over time learn to follow the code style in order to keep their name there.

> My hope is that people like to see their name when they "git blame"

Sadly, my impression is that a lot of people don't want to see their own names on git blame, because they fundamentally operate on "you break it, you buy it" mode. As long as their name isn't associated with a particular piece of code, it's not their fault that it's broken. (It doesn't matter that the code is fundamentally broken and has been broken since inception five years ago - not my fault!) Here, let me just add a quick wrapper layer on top of it so that my module can work around the bug, while at the same time making my module depend on the broken behavior...

Re: Software engineering topics I changed my mind on

#47

Post by nilkn »

dozzman wrote: post #22
alain_gilbert wrote: post #11

Earlier quoted context omitted.

I used to be an "insane weirdo", but at some point I gave up. Now, I just focus on code correctness, merge and fix the code style myself, avoiding a lot of useless back and forth. My hope is that people like to see their name when they "git blame" (what's the PC version of "blame" again?) So they will over time learn to follow the code style in order to keep their name there.

If you can, commit wholely to a parsing formatter and plug it into your CI pipeline. I've come to realise over the years that its not style I care about per-se, but consistency. With a parsing formatter and an opinionated linter, you're pretty much covered automatically across all development and developers.

Yep -- where I work, every language we use in any big way has a high-quality automated formatter, and we require all code to be formatted with these tools. It's been a dramatic improvement in code readability in general across the company. We have a few engineers who would consistently beat the formatter by a very small margin if they were formatting their code by hand, but they are the exception -- 95% of the code submitted across the company is improved by these tools.

Re: Software engineering topics I changed my mind on

#48

Post by naikrovek »

> 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.

Re: Software engineering topics I changed my mind on

#49

Post by t-writescode »

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.

My biggest frustration around ‘best practices’ is when you’re tasked with learning a new framework to consider adopting it for the company and you’re given a week and they want ‘best practices’ to come out of it.

There is no way I can learn how to write good code in a completely new framework that everyone should model after from that.

I can show what worked for a toy problem and something that’s hypothetically similar to a real problem, but that says nothing of real complexity or practices that are actually going to last more than a few months on the project.

Re: Software engineering topics I changed my mind on

#50

Post by harrisonjackson »

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.

The bigger the codebase and the more people in an org the more important coding standards are. But enforcing them should be 100% automated with a linter failing PRs that introduce incorrectly styled code (or precommit hook). That makes it so it doesn't waste code review time.
Post reply on HN