Software engineering topics I changed my mind on • Hacker News Board

Re: Software engineering topics I changed my mind on

#691

Post by dagw » Tue, Jan 26, 2021, 9:20 AM UTC

greenyoda wrote: post #634

dagw wrote: post #576

Earlier quoted context omitted.

Discuss a blocker whenever you have one. But that would require me interrupting one or more people in the middle of whatever they are doing and possibly ruining their flow. Unless there is a very tight deadline, work on something else and bring up your blocker when you know the relevant people have time to listen.

I also prefer not to interrupt others or to be interrupted. But if you send your problem as an e-mail, people can answer at their convenience. My own experience is that frequently, the act of thinking about an issue long enough to be able to formulate a coherent e-mail about it makes the solution jump out at me before I even send the message.

In truth I normally do both. I'll send an email flagging that there is a blocker I want to discuss at the next relevant opportunity.

And I've also found that writing that email leads to me solving the problem at least 50% of the times (same with writing to forum posts of StackOverflow questions)

Re: Software engineering topics I changed my mind on

#692

Post by Ma8ee » Tue, Jan 26, 2021, 10:44 AM UTC

Aeolun wrote: post #140

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 Then they are bad engineers. It is true that it’s best for their resume, but I also have my professional integrity to maintain.

That integrity isn’t worth much if you can’t get hired.

Re: Software engineering topics I changed my mind on

#693

Post by Ma8ee » Tue, Jan 26, 2021, 10:56 AM UTC

Joeri wrote: post #328

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.

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…

> imho not that hard if you have good abstractions inside the monolith

And that is the big if! The big advantage of micro services is that it forces developers to think hard about the abstractions, and can’t just reach over the boarder breaking them when they are in a hurry. With good engineers in a well functioning organisation, that is of course superfluous, but those preconditions are unfortunately much rarer than they should be.

Re: Software engineering topics I changed my mind on

#694

Post by dijit » Tue, Jan 26, 2021, 12:55 PM UTC

dagmx wrote: post #609

dijit wrote: post #591

Earlier quoted context omitted.

To be perfectly fair with the parent; It _is_ a very western ideal about heterogeneity being highly valued. I think tying emotions to it does us little favours - a prominent successful country that does not value heterogenity at all is Japan. Does Japan outcompete per capita? (The answer is no). Not sure if there are other examples of note here.

There's a difference between not valuing heterogeneous work forces versus valuing homogenous ones. The parents comment is the latter. Also you have to view the concept of heterogeneous work forces relative to the make up of the countries demographics makeup. A diverse country having a non diverse work force make up is odd statistically.

> A diverse country having a non diverse work force make up is odd statistically.

I agree, but I would also add that a company exhibiting the exact diversity representation as the surrounding country is also very odd, statistically.

Re: Software engineering topics I changed my mind on

#695

Post by Aeolun » Tue, Jan 26, 2021, 10:21 PM UTC

rebeccaskinner wrote: post #287

Aeolun wrote: post #152

Earlier quoted context omitted.

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

I've heard this argument a lot, but some of the worst codebases I've ever worked with have been heavily test-driven code. The need to have a failing test for every line of code combined with a tunnel-vision devotion to YAGNI and working in small pieced ended up creating these elaborate layers of functions that did no useful work except glue test cases together. Straighforward refactoring that might have taken an hour…

I suppose it’s possible to destroy everything. But I’d still prefer the over-tested code to the code that isn’t tested at all.

Re: Software engineering topics I changed my mind on

#696

Post by cryptica » Wed, Jan 27, 2021, 9:15 AM UTC

cryptica wrote: post #366

It sounds like were I was around my 5th year of coding. After 15 years though I changed my mind again on certain things. > Typed languages are better when you're working on a team of people with various experience levels I've changed my mind back and forth multiple times about statically versus dynamically typed languages and after 10 years I settled on dynamically typed languages as superior in almost all cases. The…

>> I can say with almost 100% confidence that sticking to dynamically typed languages leads to worse quality in the long run.

I meant to say 'statically typed languages' here but the popular narrative is so strong it must have seeped into my subconscious.

Re: Software engineering topics I changed my mind on

#697

Post by Ma8ee » Wed, Jan 27, 2021, 9:31 AM UTC

sanderjd wrote: post #266

pseudalopex wrote: post #168

Earlier quoted context omitted.

Someone told me once it's more important to design things to scale 1 or 2 orders of magnitude and be easily replaced. What you think you'll need 2 or 3 orders of magnitude from now is rarely what you need when you get there.

Yes, but it's also easy to get bogged down reimplementing, right when you have more important things to focus on to keep up with growth. Designing things to be easily replaced is easier said than done.

But when you do have proof of growth it’s much easier to finance more developers to work on the problem.

Re: Software engineering topics I changed my mind on

#698

Post by otijhuis » Fri, Jan 29, 2021, 6:50 PM UTC

skohan wrote: post #498

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…

I agree the list is very good list in general. My point of disagreement is: > 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 pr…

I consider software architecture to be extremely important and based on the other opinions of the author he probably agrees with you that it should be "just-in-time", as do I. Useless abstractions just get in the way and make things complex and hard to understand.

Yes, if a program doesn't function the way it's supposed to, it's useless. Unfortunately I've seen many developers take shortcuts and not even think about the software architecture (because "hey, it works doesn't it"). Good software architecture not only makes it much easier to build functioning software, it also makes the team function much better. The ability to maintain the software and quickly add new features depends on it. Even little things you do can contribute to a good software architecture.

Overengineering leads to a terrible mess, so does the "hey it works, I don't care about anyone who has to maintain it" mentality. Ideally you'd be somewhere in the middle. You shouldn't design everything up front and you shouldn't ignore things that are right around the corner either.

Re: Software engineering topics I changed my mind on

#699

Post by itsArtur » Sat, Jan 30, 2021, 11:42 AM UTC

Geminidog wrote: post #599

I disagree with software architecture. There's not enough theory and science in organizing code and understanding complexity. Most of what goes on here is just guessing. If you created "good architecture" it only means future requirements happened to fit your design, aka you made a good guess. Rarely does anyone design anything that is efficient in the present and adaptable to any possible future simply because there…

> Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.

That's fair, but shouldn't we strive to make the best possible guesses in the absence of said theory and science?

Re: Software engineering topics I changed my mind on

#700

Post by hycaria » Sat, Jan 30, 2021, 2:05 PM UTC

mint2 wrote: post #636

hycaria wrote: post #623

Earlier quoted context omitted.

I am a veterinarian and recruiting is way more straightforward. You’re not going to test the person on the spot. It’s way more about personality fit, what you like/dislike to do, and where you see yourself a few years later down the road. And then a real paid tryout. Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me. Sometimes it feels like the position…

1. “I am a veterinarian and recruiting is way more straightforward” 2. “Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me.” Is no one else confused by this? How common is a coding veterinarian and why do veterinarians write code?

I program as a day job and kept a small nightly gig as a veterinarian, which was indeed my degree.

How common is coding as a hobby? I used to code as a teenager as many here. Made the switch for many reasons.