Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

521–530 of 704 posts

Re: Software engineering topics I changed my mind on

#521

Is it just me or do those things seem very... obvious? I mean - almost every single one of them makes me question how can you even have a differing opinion that wouldn't immediately make you seem like you're mindlessly repeating hype phrases.

Common sense isn’t common, and sometimes it helps to write down the obvious. Obviously planes should only land with the gear down, yet not all planes have. Hence the use of checklists stating the obvious: lower the gear.

Is lowering the gear something you have changed your mind on though? ;)

Re: Software engineering topics I changed my mind on

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

In my 15 years of professional work I spent 2 years having to use Java with GWT framework and it was the most horrible, deprived of any joy, experience in my career that left me completely burned out and since then I absolutely hate Java and anything related to it.

Re: Software engineering topics I changed my mind on

#523
post #61

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

I think it is important to point out at this point, that product managers and project managers are two different jobs. Yes, neither writes code, but the product manager focuses on which features are most important for the customer and therefore needs to know a lot about the product and what makes a good product. Project managers, on the other hand, can be used even if there is no product. They require good people ski…

[deleted]

Re: Software engineering topics I changed my mind on

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

Yep, not being dogmatic about standups having to be daily, or indeed about any process, is invariably a win - do what works for the team!

I'm working in a small team just now, just 5 of us, and a short, daily standup is working well for us - and it's usually finished in 7 minutes or so.

In my last project (where I wasn't leading the standups), the teams were bigger, 10 people in each, and they went.on.forever. Neither the scrum master or PM were strict at curtailing them or keeping them relevant. Everyone hated it.

Re: Software engineering topics I changed my mind on

#526
post #42
post #26

Earlier quoted context omitted.

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.

Postgres even has JSONB support, so if you really want to store whole documents NOSQL-style, you can - and you can still use all the usual RDBMS goodness alongside it!

Postgres really is a wonderful database.

Re: Software engineering topics I changed my mind on

#527

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'm fine with using the term "frail little minds" for people with real-world levels of TDD zealotry.” This is disgusting behavior on your part. You should be ashamed. Even more so for the mental gymnastics you’ve written in this spastic and bizarre comment to defend and endorse using flippantly insulting language. The level of intellectual dishonesty in what you say is just staggering. Absolutely shambolic on you…

>This is disgusting behavior on your part. You should be ashamed.

This is hollier than thou virtue signalling on your part. You should be shunned.

Also, hypocritical. You're against "frail little minds" but are OK with yourself using "disgusting behavior" and "you should be ashamed", like some tv-evangelist...

>Even more so for the mental gymnastics you’ve written in this spastic and bizarre comment to defend and endorse using flippantly insulting language.

No mental gymanstics required. Devs are adults. The "ocassional flippantly insulting language" if fine and has been part of team work since forever.

Not to mention TFA author didn't target anyone in particular, but a category of people with zealotic behavior.

If you can't call out stupid ideas as stupid, and zealots as such, then we've regressed at childish levels of protection from the real world (which perhaps is all the rage in some rapidly infantilizing areas of the world, enabled early by helicopter parents).

Re: Software engineering topics I changed my mind on

#528
post #62

The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

No, you should use proper abstractions to allow you to "easily" replace components down the road. There's no point in planning, designing, or building your application for a million users because by the time you get there: 1 - the business needs will be radically different from what you expected initially, and 2 - you'll have dozens more engineers who will probably do the actual work. It's exceedingly unlikely that the architecture decisions that you made will be relevant at that time.

Also, the overwhelming majority of companies that claim that they need to scale into the millions of DAU will never make it there.

Re: Software engineering topics I changed my mind on

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

For the project I'm currently working on, the customer mandates that we must use SonarQube, Fortify and Nexus IQ.

Not once has any of them found any kind of security issue. In fact every single thing they have raised has been a false positive, or just plain time wasting (e.g. forcing some arbitrary level of branch coverage). Also, they can be so slow - more time is spent in the build pipeline on these tools than is spent in actual build, test and deployment combined (even including integration tests)! Fortify is particularly slow (up to 10 minutes!), and provides no value whatsoever.

I've used SonarQube on several other projects too; it seems to be very popular in enterprise circles in particular. Never once have I seen it raise a security issue. On occasion it points out the odd accessibility issue, but that's it.

Re: Software engineering topics I changed my mind on

#530

Earlier quoted context omitted.

In theory, no difference. In practice, good standups to me always feel like a casual conversation, and bad standups always feel like people speaking off a script like bad actors.

Why not just have casual conversations instead? Standups are one those things that people disagree on endlessly without discussing context - their worth depends on the team. On my current team they're worthless. I'd rather have casual conversation, but that's like squeezing blood from a stone. Departure planning underway.

> Why not just have casual conversations instead?

Scheduling it daily is how you have these casual conversations.

Post reply on HN