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

441–450 of 704 posts

Re: Software engineering topics I changed my mind on

#441

Post by iovrthoughtthis »

crescentfresh wrote: post #267
temporallobe wrote: post #150

Earlier quoted context omitted.

Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…

> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.

In a standup you should be able to say “i’m not really doing anything atm”, “i’m writing tests for x”, “i’m documenting y” without fear of someone asking you justify yourself.

Re: Software engineering topics I changed my mind on

#442

Post by jmiserez »

Falkon1313 wrote: post #404
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,…

I generally agree. But static analysis tools are still pretty dumb and sometimes cause extra work to no benefit. Flagging a method for cyclomatic complexity when it uses a case statement that is blatantly obvious and simple to any human seeing it, for example. Or just happening to notice a bunch of issues in file B when you commit file A but didn't even touch file B. Overall it's good, I like it, but with the caveat…

Cyclomatic complexity IMHO isn't a good metric for code complexity as understood by humans, but sometimes it can be insightful especially when it's unexpected.

My favorite static analysis issues are the ones that flip-flop between two issues, I love doing "merge this if statement with the enclosing one" only to get "expressions should not be too complex" after I've merged them.

As long as you have the power as the developer to override the tool and mark issues as won't fix (with rationale) I think it's fine. If not, the ruleset needs to be really good and as minimal as possible. Otherwise you'll just get crappy but compliant code which isn't helping anyone.

Also, it sometimes makes sense to leave suboptimal but old and correct code as-is to preserve the Git history or because the suggested change doesn't actually make the code any better. And finally, these tools do still generate false positives. While it makes sense to thoroughly review each of these with a coworker, you should still be able to mark them as false positives.

Re: Software engineering topics I changed my mind on

#443

Post by watwut »

js8 wrote: post #397
Jestar342 wrote: post #375

Earlier quoted context omitted.

That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck. Natural siloing happens, but you (team) should be striving to reduce it, not encourage it. *More accurately: work can only proceed on that something when X is available*

My point is, it doesn't have to be black and white. If your expert is less available, or has too much of the same work, or you just want a backup, you just start training someone else to be an expert in that area too. It's not costlier than what you propose, it seems that it is always better to start with having a designated expert rather than to dilute the expertise so much than no one really is.

It does not work, at least did not worked for us. The problem is that in any single situation it is easier for expert to solve it alone then explain and when then there is sudden need to explain, expert can't do it effectively. Because he was not explaining for years.

Plus, you end up being in a limited box and have harder time to grow by learning new things - project structure keeps you in box and you can't easily expand it by taking tasks to learn something new.

Finally, expert is sort of fake expert - expert only because others are kept clueless. Not because he would had such great knowledge objectively, but because we decided this is only his area. There is no other engineer to discuss issues with our to compete with.

Re: Software engineering topics I changed my mind on

#444

Post by throwaway-8c93 »

koonsolo wrote: post #389

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

My score is similar, and kind of agree. The eerie part is that the intuition can discern a good hire within 2 minutes with fairly high probability, and within 10 minutes with near certainty. The rest of the interview process is just padding to figure out whether the intuition is not wrong (it seldom is).

That intuition is some mashup of the candidate speaking on point, pragmatism, non-equivocation, admission of ignorance on some topics, English proficiency (1), etc. It's also impossible to codify or quantify, hard to convey and non-transferable.

(1) - here in Europe, English fluency, diction and (lack of) thick accent correlate highly with overall ability

Re: Software engineering topics I changed my mind on

#445

Post by majkinetor »

I would add just one

- Automation of everything is what you need in 99% of cases. There are almost 0 cases when you automate something and it turns out that you could have done it more efficiently manually (even in that case, learning experience makes it usually worth it, while such manual work provides almost 0 XP).

Re: Software engineering topics I changed my mind on

#447

Post by disgruntledphd2 »

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 why I like black, for Python. It doesn't have any configurable settings, which means way less arguments.

Re: Software engineering topics I changed my mind on

#448

Post by rmu09 »

ng12 wrote: 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…

Sometimes it is the customers that need shielding from the engineers.

I remember a situation where defcon was raised to 2 when the head of our unit found out that a particular engineer went to a meeting with a particular customer on his own.

Re: Software engineering topics I changed my mind on

#449

Post by iovrthoughtthis »

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

Adherence to (imo) bad linting rules have forced the early crystallisation of architecture as arbitrary abstractions simply to please the static analysis gods.

Code style is fine to keep consistent but sometimes concepts just aren’t battle tested enough to warrant their own abstractions yet and committing to one to please a cyclomatic complexity / line count score is actually just creating more work for some future engineer who is tasked with the job of re-engineering the solution.

Re: Software engineering topics I changed my mind on

#450

Post by hardlianotion »

captrb wrote: post #284
potta_coffee wrote: post #185

Earlier quoted context omitted.

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.

A few years ago, my good friend used to say that the first two main duties of a financial quant library are string manipulation and memory allocation.
Post reply on HN