Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

271–280 of 704 posts

Re: Software engineering topics I changed my mind on

#271
> Clever code isn't usually good code. Clarity trumps all other concerns.

I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this.

They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, the performance benefits you get from that don't outweigh the negative impacts.

Re: Software engineering topics I changed my mind on

#272
post #231

Earlier quoted context omitted.

I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).

To this end, I have a small, paper-sized whiteboard that I can scrawl onto on hands at all times. I bought a couple packs of the ultra-fine expo markers, and it’s been a boon. Great for quickly noting things down that don’t need to last. Having both is important, though: you need to be able to preserve the things that matter, that you may need later on.

That's why phones have cameras.

Re: Software engineering topics I changed my mind on

#273

At year 15 or so, he'll change his mind about project managers. Project management is one of those broken things in the industry because it's never taken seriously. People promoted to PM generally receive no training or mentorship. In fact, sometimes the only way to break into management is to quit your job and start somewhere else with a slightly exaggerated resume. And sometimes the only qualification required is a…

Agree wholeheartedly.

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

I read that and instantly thought "yeah but which 90-93%" because the 7-10% that are great are not easy to differentiate on paper. And this can easily apply to most auditors, QA, or sales folks too. The ones really good at their job are hard to find and the rest are just being asked to do difficult things with little resources.

Re: Software engineering topics I changed my mind on

#274
post #263

> Typed languages are better when you're working on a team of people with various experience levels. Even if you are working alone you should probably treat it as working with people with various experience levels if it is code that you are going to have to periodically deal with in the future. When older you has to come back to the code, older you should be more experienced that younger you in general, but older you…

I think using typed languages can still be good even if alone assuming you are experienced enough with it, you are more likely to write everything correctly on the first try, but some other things like writing good commit messages and things like that I never do. I have never made use of git history to debug some personal project of mine.

Re: Software engineering topics I changed my mind on

#275

The TDD one I sort of half agree with. Purism and zealoutry are rarely a good reaction to anything, but I've seen a lot of dodgy code that, if it had been written with at least testability in mind, or with a test first it wouldn't have been half as dodgy.

>test first it wouldn't have been half as dodgy. Feel part of this, in my very little experience, is with tests focus is getting smallest thing working so less to go wrong

I think another commenter said something poignant around this as well; it’s great too if you are working to a spec. For exploration it might be a cumbersome approach to go all in with.

Re: Software engineering topics I changed my mind on

#276
post #164

Earlier quoted context omitted.

On my reading, this is the exact same problem, not the exact opposite problem. The break-even bar for a reasonable monolith is a lot lower than for microservices, so the GP's question is specifically asking, under a hypothetical where the team simply uses a monolith, what benefits the team would miss out on relative to microservices. If there are none, or they aren't relevant to the project scenario, then microservic…

The point is it can be engineers pushing back against managers. Not just managers pushing back against engineers.

Aha! Opposite in that direction; I misread. (I'm also an engineer pushing back on managers who want microservices.)

Re: Software engineering topics I changed my mind on

#277
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 guess I don't like massive slow IDEs and slow compilation times. I just feel so slow when working with Java as well my mind gets distracted and frustrated. Maybe it is my personality flaw to not have that type of patience.

Re: Software engineering topics I changed my mind on

#278

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful,…

This is why I lean towards serverless monoliths these days. It works great.

Re: Software engineering topics I changed my mind on

#279

Earlier quoted context omitted.

> and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this No strawman required. There are real devs with extreme TDD zealotry. It's very possible that the author has worked with such devs, and I see no reason to doubt his experience. Your use of the word "strawman" above, doesn't magically make such devs which push TDD with zealo…

I think this whole thread is an example of The Weak Man argument in action, it’s neat to see it in real life just after it was posted on HN.

I think it's more about making mountains out of molehills and ignoring the context and substance of TFA.

Re: Software engineering topics I changed my mind on

#280
post #269

Earlier quoted context omitted.

It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.

We decided early on that a daily scrum was just too frequent to be effective for our team, so went to 2x per week. When we started working from home, we added a "keep in touch" meeting for the other 3 days of the week just to stay connected.

Our standups (for a team of four) are about 15 minutes. Then we just leave the zoom on and co-work together out loud for an hour or two. It's pretty priceless the stuff that comes up during that time.
Post reply on HN