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

281–290 of 704 posts

Re: Software engineering topics I changed my mind on

#281

Post by tasty_freeze »

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

I'm less concerned about which coding style, but it is important that everyone (mostly) follows the same coding style.

Not all coding style rules are minutia. I've worked on code bases which have a mix of hard and soft tabs, with tabs sometimes mixed in the middle of the line, not just at the start of line, and where different authors use tabstop=2 or 3 or 4 or 8, all in the same file. And comment lines that are more than 400 characters wide.

Re: Software engineering topics I changed my mind on

#282

Post by beagle3 »

tasty_freeze wrote: post #281

> People who stress over code style, linting rules, or other minutia are insane weirdos I'm less concerned about which coding style, but it is important that everyone (mostly) follows the same coding style. Not all coding style rules are minutia. I've worked on code bases which have a mix of hard and soft tabs, with tabs sometimes mixed in the middle of the line, not just at the start of line, and where different aut…

This is completely and trivially solvable via a checkin filter that refuses tabs (or expands them to a given number of spaces). Why fuss about it?

Re: Software engineering topics I changed my mind on

#283

Post by ng12 »

quelltext wrote: post #233
01100011 wrote: post #81

Earlier quoted context omitted.

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…

This! Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc. Yet, the product manager position isn't really staffed, and neither is the project manager one. So, all the additional work beyond design and coding also falls on the owning engineer. And since we are frugal that engineer is happy to get maybe 1 additional engineer assigned to help. But…

> Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc.

This is why I like the way the linked article put it: you can lose most PMs without sacrificing efficiency. I would imagine a great deal of this stuff isn't actually important and only hampers the team's velocity. A PM will make it their job to make sure it gets done, if there is no PM the unimportant stuff will fall by the wayside.

Re: Software engineering topics I changed my mind on

#284

Post by captrb »

potta_coffee wrote: post #185
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…

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

Especially true when the services are all stateless. If there isn’t a conway-esque or scaling advantage to decoupling the deployment... don’t.

I had a fevered dream the other night where it turned out that the bulk of AWS’s electricity consumption was just marshaling and unmarshalling JSON, for no benefit.

Re: Software engineering topics I changed my mind on

#285

Post by beagle3 »

mewpmewp2 wrote: post #277
thayne wrote: post #230

> Java isn't that terrible of a language True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.

What I hate is that I can't understand anything when I try to understand existing code with all the abstractions going on and having to jump through 100s of files with so much boilerplate and clutter, trying to understand how the logic binds together. And then just interfaces everywhere, I can't even jump with an IDE, I have to find where this interface magically gets injected first to find the actual logic. Also I g…

Structured programming saved us from “spaghetti code” but Java culture introduced “spaghetti class hierarchy” and practitioners seem to practice it quite religiously.

Re: Software engineering topics I changed my mind on

#286

Post by mattdeboard »

quelltext wrote: post #203
free_rms wrote: post #125

Earlier quoted context omitted.

The linked post said project manager. Good PRODUCT managers, in small numbers, are worth their weight in gold IMO. Researching/talking to users takes time, making decks takes time, stepping back and surveying the landscape takes time. It's worth having someone doing that.

Oh god, I hate the PM abbreviation. Product managers and project managers have a bit of overlap (as the former also do project management to an extent, just like engineers), but they are different and having them provides different benefits. Why do we abbreviate both with PM? I never quite know which is referred to.

Don’t forget “program manager” too

Re: Software engineering topics I changed my mind on

#287

Post by rebeccaskinner »

Aeolun wrote: post #152
dnautics wrote: post #115

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 attentio…

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

I've heard this argument a lot, but some of the worst codebases I've ever worked with have been heavily test-driven code. The need to have a failing test for every line of code combined with a tunnel-vision devotion to YAGNI and working in small pieced ended up creating these elaborate layers of functions that did no useful work except glue test cases together. Straighforward refactoring that might have taken an hour or two ended up taking days because every few keystrokes had to be validated by intermediate tests that would be invalidated by the next incremental phase of the refactor.

Granted that particular team was an extremely low-skill team in general, and I've used TDD now and again successfully when it fit my needs, but that experience was a pretty strong counter-example to the strong claims made by TDD proponents about how it improves the quality of code.

Re: Software engineering topics I changed my mind on

#288

Post by beagle3 »

vmception wrote: post #224

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql I use NoSql because RDBMS is a premature optimization for me My experience with ORMs especially ORMs I didnt chose is that they are frail, assume too much and I often end up writing my own plain text queries anyway, all so that I can get a result from the database in object form, but without bogging down the data…

The problem you point to is the ORM, not the DBMS. And if you think “of course, but how can you OOP properly without objects? (And thus ORM if you use an RDBMS)” — you might join some of us in the conclusion that OOP is way overrated.

Don’t get me wrong, it is exceptionally useful when it’s a natural fit, like in GUI systems and some aspects of game programming.

But in many places, it is completely unfitting, and complicated things (similarly for FP, BTW)

Re: Software engineering topics I changed my mind on

#289

Post by t-writescode »

jdlshore wrote: post #262
t-writescode wrote: post #247

Earlier quoted context omitted.

Then it’s not (edit: pure) TDD. The TDD purists I’m familiar with think if you write any code before you write the tests, you’re doing it wrong.

That’s a common misunderstanding of TDD, but it’s incorrect. TDD is an incremental cycle of write test, write code, refactor, repeat. Typically less than 5 lines at a time.

Given the order of the words you said, writing tests comes before writing code, as I said.

Re: Software engineering topics I changed my mind on

#290

Post by rmk »

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,…

People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin to see the forest for the trees, because the trees are mostly uniform) and (c) onboarding or familiarising with new codebases, including new areas of large codebases.
Post reply on HN