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

481–490 of 704 posts

Re: Software engineering topics I changed my mind on

#481

Post by edumucelli »

temporallobe wrote: post #150
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…

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…

I do not understand why people have to wait to discuss the blockers? Discuss a blocker whenever you have one.

Re: Software engineering topics I changed my mind on

#482

Post by pydry »

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…

>can supercharge your productivity by giving you those dopamine rushes

These dopamine rushes unfortunately have a nasty side effect of turning people into TDD zealots.

TDD works great where it works, but it often has a nasty side effect of spewing out tests which don't tell you anything useful and demand near constant maintenance to keep the build pipelines alive.

The zealots seeking a dopamine high will tolerate this in pursuit of their high and will churn out unit tests. The zero-benefit-high-cost unit test maintenance eats into the entire team's testing budget without producing a commensurate return on investment.

Re: Software engineering topics I changed my mind on

#483

Post by cygned »

edumucelli wrote: post #481
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…

I do not understand why people have to wait to discuss the blockers? Discuss a blocker whenever you have one.

Standups allow you to see blockers before they are there just by having a bigger picture of what’s happening.

Re: Software engineering topics I changed my mind on

#484

Post by u678u »

Chris_Newton wrote: post #330
PragmaticPulp wrote: post #41

Earlier quoted context omitted.

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume The sad thing is, they might well be right. People used to not get hired for a job involving MySQL because their DB experience was with Postgres, but usually more enlightened employers knew better. Today, every major cloud provider offers the basic stuff like VMs and managed datab…

Agreed, I found it really hard to get good roles 5 years ago. Then I worked on some cool shiny stuff - in general I dont like microservices, k8s, React/JS but it opens a whole new world of jobs.

Re: Software engineering topics I changed my mind on

#485

Post by u678u »

bawolff wrote: post #26
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…

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.

hey.com is the latest one that is on mysql.

Re: Software engineering topics I changed my mind on

#486

Post by mlthoughts2018 »

coldtea wrote: post #244
mlthoughts2018 wrote: post #129

Earlier quoted context omitted.

Absolutely not. Setting up a strawman “absolute purist” (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) and then using needlessly insulting or belittling language to condemn the fake strawman is totally ridiculous. Your attempted defense of it is not acceptable. You could just as easily say something like, “People who t…

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

Re: Software engineering topics I changed my mind on

#487

Post by lillecarl »

mabbo wrote: post #480
lillecarl wrote: post #465

Earlier quoted context omitted.

What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?

If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.

That's very condescending. I'm asking because I don't see why my colleagues would be any better than they are if they were black, brown, jewish, muslim, female in various combinations, maybe I hold my colleaguestoo high?

Re: Software engineering topics I changed my mind on

#488

Post by Nimitz14 »

mabbo wrote: post #480
lillecarl wrote: post #465

Earlier quoted context omitted.

What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?

If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.

Please. Those studies are a joke. Imo those competitors will go down the drain just like google is doing right now. Time will tell which one of us is right. ;)

Re: Software engineering topics I changed my mind on

#490

Post by austincheney »

joatmon-snoo wrote: post #470
austincheney wrote: post #179

Earlier quoted context omitted.

There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.

Re-inventing the wheel can be useful for learning, but can have very real costs, often in the form of production outages. * "You can usually use user metadata field X for billing" - except for those users for whom field X actually maps to something else, for tech debt reasons. (Is it stupid and bad? Yes. Is anyone going to be able to fix it this year? No. Is this going to result in Very Big Customer TM getting mad? Y…

> often in the form of production outages

Completely unrelated. If you have production outages resulting from new code you have serious gaps in your certification process, especially so if the new code covers existing process/requirements. You are probably insecurely reliant upon dependencies to fill gaps you haven’t bothered to investigate, which is extremely fragile.

The benefit of code reuse is simplification. If a new problem emerges with requirements that exceed to current simple solution you have three choices:

1. Refactor the current solution, which introduces risk.

2. Roll an alternative for this edge cases and refactor after. This increases expenses but is safer and keeps tech debt low.

3. Roll an alternative for this edge case and never refactor. This is safe in the short term and the cheapest option. It is also the worst and most commonly applied option.

Post reply on HN