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

311–320 of 704 posts

Re: Software engineering topics I changed my mind on

#311

Post by christkv »

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

We always run standups in the same way. What did I work on yesterday, what am I working on today and finally impediments or help required as well as general organizational stuff that might impact the team.

Re: Software engineering topics I changed my mind on

#312

Post by Chris_Newton »

tikhonj wrote: post #189
windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up . If something is important, why would you wait for tomorrow's standup? If something isn't important, w…

That seems like a reasonable concern to me, and something that could apply to almost any communications that are on a regular schedule, whether it’s a daily team meeting or an annual review with your boss.

My father said something to me when I was nervous before my first annual review in my first job, and it has stuck with me ever since: nothing anyone says in that review should ever be a surprise. Whether it’s good or bad, if your management are doing their job, everyone who needs to know about it should have known when it became relevant, not on the anniversary of your employment.

I suspect there is more value in some types of regular but short technical meeting at the moment, when many colleagues aren’t in close proximity at work and ad-hoc informal discussions are less likely to serve the same purpose. But as someone who’s primarily worked from home for years, I’d usually still prefer to arrange a group call or physical meeting with whoever actually needs to be there when there’s something specific to discuss, rather than assuming in advance that any particular tempo will be the right one.

Re: Software engineering topics I changed my mind on

#313

Post by dragontamer »

projectileboy wrote: post #299
crescentfresh wrote: post #267

Earlier quoted context omitted.

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

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.

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

As someone who did sales early in my career... acting off of a script correctly feels like a casual conversation to the one you're selling to.

If your script-reading is bad, that's because you haven't practiced enough. Having a script isn't necessarily a bad thing, and is in fact very useful in keeping focus.

Re: Software engineering topics I changed my mind on

#314

Post by karmasimida »

Very insightful post. Best for this month maybe :)

Some of which I like most:

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

> Bad code can be written in any paradigm

> So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot

> Designing scalable systems when you don't need to makes you a bad engineer

> In general, RDBMS > NoSql

> DRY is about avoiding a specific problem, not an end goal unto itself

Overall, software engineering is NOT a solved domain, nor it needs to be. Best practices works best solving others' problem, but most likely, your problem is different, and you are different as well.

Don't be scared to do things in the way that you think is not approved. Exploration is necessary, because unknown is inevitable.

Stay fluid and vigilant, be skeptical yet adaptive.

Re: Software engineering topics I changed my mind on

#315

Post by cercatrova »

After reading these, I am wondering how anyone could've thought differently, as I agree with them all and it seems to me that to disagree with any of them doesn't seem to be reasonable. For example, typed languages are of course better than untyped ones, especially for large codebases with multiple levels of experience of the people who write them.

In other words, these seem to be exactly the opinions that the majority of HNers would agree with, and it is one of the least controversial lists I've ever seen.

Re: Software engineering topics I changed my mind on

#316

Post by orobinson »

Shorel wrote: post #257
busterarm wrote: post #183

Earlier quoted context omitted.

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specific…

There are only two options for me: MySQL or Postgres. And using AWS generally means using Aurora. Then the choice is already made. Not hard at all. Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.

Just curious, for what reasons would you choose MySQL over Postgres?

Re: Software engineering topics I changed my mind on

#317

Post by jdlshore »

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

Earlier quoted context omitted.

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.

Writing one test comes before writing a few lines of code. It’s iterative. Tests (plural) don’t come before code. They happen at the same time.

Re: Software engineering topics I changed my mind on

#318

Post by hordeallergy »

projectileboy wrote: post #299
crescentfresh wrote: post #267

Earlier quoted context omitted.

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

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.

Re: Software engineering topics I changed my mind on

#319

Post by njharman »

xmprt wrote: post #293
woutr_be wrote: post #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, t…

Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function. The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"

Faster code is not fine.

Faster code should only be written after finished product is shown to be too slow for purpose and after profiler has shown which parts of code are worth optimizing.

Re: Software engineering topics I changed my mind on

#320

Post by njharman »

DDSDev wrote: post #6

> DRY is about avoiding a specific problem, not an end goal unto itself. To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. The former leads to elegant abstraction, while the latter just leads to functions with…

I tend to think of it in terms of bugs or less so, feature addition. Weighted by likelihood of bug.

If there is bug, will someone have to fix it in one place. Or, remember it’s in 7 places. If later I DRY.

Post reply on HN