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

11–20 of 704 posts

Re: Software engineering topics I changed my mind on

#11

Post by alain_gilbert »

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.

Re: Software engineering topics I changed my mind on

#12

Post by dboreham »

dimtempo84 wrote: post #7
chenmike wrote: post #5

Earlier quoted context omitted.

Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.

Yes, we use golangci-lint for our few Go projects, which works well. However, most of our projects are in Java, and the mistake of our team was to never have our Checkstyle break the build. So, the result is many Java repos with a variety of coding styles.

This is just how life turns out ime. Focus on more important things.

Re: Software engineering topics I changed my mind on

#13

Post by cbdumas »

> 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 "microservices" are absolutely astounding. Who needs joins? Who needs relational integrity? Who needs flexible query patterns? "It just has to scale"!

Re: Software engineering topics I changed my mind on

#14

Post by david_allison »

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.

> what's the PC version of "blame" again?

JetBrains uses "annotate"

Re: Software engineering topics I changed my mind on

#15

Post by virmundi »

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…

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.

Re: Software engineering topics I changed my mind on

#17

Post by chenmike »

dboreham wrote: post #10
chenmike wrote: post #5

Earlier quoted context omitted.

Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.

Then you get to have many meetings about which litter and lint rules to use.

This is a tiny fraction of the time that it takes to comment on PRs/CLs in perpetuity. The alternative is just to literally not care about formatting which if you are able to do more power to you, but I could not imagine working on such a team. To me it’s somewhat akin to saying that all that matters in writing is the ideas, not the formatting of a document.

Re: Software engineering topics I changed my mind on

#18

Post by evan_ »

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.

Credit

Re: Software engineering topics I changed my mind on

#19

Post by wegs »

I predict the following changes:

1) Typed languages are worse, and you want people with high levels of competence.

2) Java actually IS terrible. You win very little by designing for incompetent coworkers. Plan for competence, and hire appropriately. Small elite teams beat large incompetent teams every time. See #1.

3) Thinking through scalability upfront matters in many systems. Not all systems. Many systems.

4) SOLID is one way to do things, and not always the right one. OO isn't always the right one either.

5) YAGNI is more complex... you shouldn't build what you don't need yet, but you should architect for reasonable changes to requirements. Scope out all possible features early in the system design, create an architecture that supports them, and then implement the minimum viable system which can be easily incrementally refactored into that architecture.

6) There are ways to interview well. When you figure them out, you'll notice they give you a competitive advantage (while sharing them doesn't make the industry more efficient as a whole, and makes them less effective, so if you're smart, you'll keep them to yourself).

Post reply on HN