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

421–430 of 704 posts

Re: Software engineering topics I changed my mind on

#421

Post by Chris_Newton »

tikhonj wrote: post #206
ithrow wrote: post #194

Earlier quoted context omitted.

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 specifications. Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?

You (mostly) don't have to deal with data migrations with statically typed languages. Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.

Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.

Yes, and on top of that, code-only changes need to be internally consistent to make sense but DB schema changes almost inevitably require some corresponding code change as well to be useful. Then you have all the fun of trying to deploy both changes while keeping everything in sync and working throughout.

Re: Software engineering topics I changed my mind on

#422

Post by Jestar342 »

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.

Nobody has said it should be except for you. As I said it will occur but you should strive to spread information and learning as much as is reasonable.

Re: Software engineering topics I changed my mind on

#423

Post by skohan »

Very good list in general, but I would disagree with one point:

> Software architecture probably matters more than anything else

The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful.

The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions.

The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"?

After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.

Re: Software engineering topics I changed my mind on

#424

Post by Chris_Newton »

potta_coffee wrote: post #357
Joeri wrote: post #328

Earlier quoted context omitted.

The idea is that you can scale different parts of the system at different rates to deal with bottlenecks. With a monolith, you have to deploy more instances of the entire monolith to scale it, and that’s if the monolith even allows for that approach. If you take the high load parts and factor them out into a scalable microservice, you can leave the rest of the system alone while scaling only the bottlenecks. All of t…

I understand how microsercices work, but I'm referring to a specific kind of antipattern where an application is arbitrarily atomized into many small services in such a manner that there's zero scaling advantage. Imagine making every function in your application a service as an extreme example.

This seems to be an example of a more general antipattern in software development, where a relatively large entity is broken down into multiple smaller entities for dogmatic reasons. The usual justification given is how much simpler each individual entity now is, glossing over the extra complexity introduced by integrating all of those separate entities.

Microservice architectures seem to be a recurring example of this phenomenon. Separating medium to long functions into shorter ones based on arbitrary metrics like line count or nesting depth is another.

Re: Software engineering topics I changed my mind on

#425

Post by eecks »

busterarm wrote: post #183
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, 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…

Which parts are hard?

Re: Software engineering topics I changed my mind on

#427

Post by theshrike79 »

radicalbyte wrote: post #415
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…

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / culture…

One more from me, with 20 years of experience.

Some people are force multipliers. They make everyone around them more efficient. BUT people like this are hard to determine with Standard Performance Indicators.

Personal anecdote:

I had to fight tooth and nail to keep a junior coder in my team because "she wasn't performing well". Yes, she didn't commit often and her code quality was average at best. Tasks took longer than average to complete as well.

But what she DID DO was keep the two auteur seat-of-their-pants 10x coders in her team focused and on task, made sure to ask the correct questions and had them document their work. She also took over their customer-facing stuff so the socially awkward 10x pair didn't need to do that.

None of this showed up on standard performance indicators.

Now she's a team lead at the same company, managing the two 10x-ers.

Re: Software engineering topics I changed my mind on

#428

Post by OJFord »

ozim wrote: post #363
hordeallergy wrote: post #318

Earlier quoted context omitted.

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.

It should be, but not everyone on the team has to be confident. Not everyone has to be outspoken, not everyone has to have perfect pronunciation. Not everyone is able to structure their thoughts in 1 minute, even though they are able to work on complex systems. What you want from "what you did yesterday, blockers, what you will do today" script is a framework for conversation starter, conversation scope and having so…

Personally I'd like a stand-up where it's ok not to have anything to say, like yeah, WIP, no problems, no blockers (except being here talking about it instead of doing it..!) etc.

Fully agree I would prefer it later. Not just 20min, I typically start ~1h before ours anyway, but it hangs over me all that time. I'd like to spend most of the day working on something and then stand-up in the afternoon, I'd be more likely to have an issue someone could help me with, or otherwise on my mind to discuss.

Re: Software engineering topics I changed my mind on

#429

Post by _y5hn »

hordeallergy wrote: post #318
projectileboy wrote: post #299

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.

Careful what you wish for. In open landscapes and in meetings with business side, there's endless pointless chatter about everything else but doing their job. I'm not a devotee to overwork and squeezing blood out of stone type of worker. However, the directionless chatter, general incompetence, lack of inquisitiveness and awareness become energy-draining over time.

Status report is when a team say the same things every day and every week, nothing changes and there's nothing new to be learned. This is Waste.

Daily scrum is meant to encourage collaboration, inspiration and brief sharing of information. However, when driven by business needs alone, it becomes another pointless status report. On the flip side, if daily scrum takes off, it should be allowed to continue as a new meeting afterwards, but is also a sign that there's not enough coherency in the group with the current practice.

Re: Software engineering topics I changed my mind on

#430

Post by dvfjsdhgfv »

radicalbyte wrote: post #415
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…

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / culture…

> * The root cause of the above is often insecurity; and it can be coached / cultured away.

It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.

Post reply on HN