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

Re: Software engineering topics I changed my mind on

#461

Post by vendiddy » Sun, Jan 24, 2021, 1:06 PM UTC

mbeex wrote: post #413

dnautics wrote: post #153

Earlier quoted context omitted.

Refactoring is quadratically more difficult if you don't have tests.

Not this simple. Refactoring might mean invariance, but the more comprehensive your tests are, the more they also test the moving parts. That means, they have to be changed too. Many people forget the maintenance costs (and this has a much broader meaning than the refactoring example). Tests themselves have to be considered as a software (or more general) artifact with a cost.

For this reason, I prefer going heavy with integration tests early in in a design.

This way I'm not rewriting tests every time I need to rip apart and restructure the internals but I still have the safety net of refactoring without breaking the external contract.

Re: Software engineering topics I changed my mind on

#462

Post by dbattaglia » Sun, Jan 24, 2021, 1:07 PM UTC

throwawayboise wrote: post #53

Coming up on 30 years. I agree with most of your observations except standups. In my experience daily standups are a waste of time. Maybe I've just had bad luck with them?

Same here. At my current job it’s literally impossible for my team to pull off as we’re spread across North and South America, Europe, Japan and New Zealand. Instead we have two weekly meetings, one friendlier to western countries and the other better for Asia pacific, both recorded, where we review agenda items added (by anyone who wants to add something, including folks at other teams) and then a quick review of major team projects status. I personally find it much more productive than a 15-30 minute scrum stand up where people either say “same as yesterday” or drone on for 5 minutes straight, depending on their personality.

Re: Software engineering topics I changed my mind on

#463

Post by jiggawatts » Sun, Jan 24, 2021, 1:09 PM UTC

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.

I recently decided to benchmark some Azure services for... reasons.

Anyway, along this journey I discovered that it's surprisingly difficult to get a HTTPS JSON RPC call below 3ms latency even on localhost! It's mindboggling how inefficient it actually is to encode every call through a bunch of layers, stuff it into a network stream, undo that on the other end, and then repeat on the way back.

Meanwhile, if you tick the right checkboxes on the infrastructure configuration, then a binary protocol between two Azure VMs can easily achieve a latency as low as 50 microseconds.

Re: Software engineering topics I changed my mind on

#464

Post by pseudalopex » Sun, Jan 24, 2021, 1:10 PM UTC

axaxs wrote: post #212

pseudalopex wrote: post #202

Earlier quoted context omitted.

It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.

Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.

Lots of companies have teams for back end, front end, ops, etc.

Slack is a good way for things to get lost in the noise or decided by whoever is in the channel at the time. Email doesn't have those problems but discussions can stretch out over days. And people speak more freely when there isn't a written record.

Re: Software engineering topics I changed my mind on

#465

Post by lillecarl » Sun, Jan 24, 2021, 1:18 PM UTC

mabbo wrote: post #456

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…

> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…

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?

Re: Software engineering topics I changed my mind on

#466

Post by jmiserez » Sun, Jan 24, 2021, 1:21 PM UTC

rebeccaskinner wrote: post #294

thayne wrote: post #230

> Java isn't that terrible of a language True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.

This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer…

>deeply unpleasant to use, such a profoundly nightmarish vampire of morality, so utterly and irredeemably cruel in it's ability to strip all joy out of the art of software development...

Oh my...

As a Java developer, I'm curious. Can you elaborate a bit? Was this some really old version of Java, a horrible IDE, crazy frameworks, something else? Am I living in a nightmare and just haven't woken up yet?

I realize that performance has been an issue in the past, but that has been solved. I've used plenty of other languages (also functional ones), and they all have their quirks. In what ways is Java perceived to be worse than other languages nowadays?

Re: Software engineering topics I changed my mind on

#467

Post by eecks » Sun, Jan 24, 2021, 1:23 PM UTC

mkl wrote: post #440

eecks wrote: post #434

I seem to be the only one confused by the list. Could someone clarify? When the author says "Java isn't that terrible of a language." in the "Things I've changed my mind on" are they saying they used to think Java was not a terrible language and now think the opposite? (i.e. current opinion is that Java is a terrible language.)

He introduces that list with "Things I now believe, which past me would've squabbled with". It seems pretty clear.

Ah thanks, I must have skipped over that line.

Re: Software engineering topics I changed my mind on

#468

Post by throwaway08320 » Sun, Jan 24, 2021, 1:23 PM UTC

xxs wrote: post #407

Falkon1313 wrote: post #387

Earlier quoted context omitted.

I think that depends on what you're doing with the data. If you're just grabbing one thing and working with it, or looping through and processing everything, maybe not. But if you're doing more complicated query-like stuff, especially if you want to allow for queries you haven't thought of yet, then the DB might be useful. Sometimes a hybrid of query-able metadata in a DB along with plain old data files is good. That…

>doing more complicated query-like stuff That's some kind of fallacy - standard datastructures would totally destroy any-sql-alike thing, if it comes to performance (and memory footprint). I guess it does depend on where the background comes when it comes to convenience - or how people tend to see their data. However like I said - for close to 3 decades I have not seen a single reason to do so. On the contrary I've h…

> for close to 3 decades I have not seen a single reason to do so

Evidently you don't have dataset far exceeding the amount of RAM you can afford.

For a good example look at LMDB.

Re: Software engineering topics I changed my mind on

#469

Post by pseudalopex » Sun, Jan 24, 2021, 1:24 PM 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.

The point is you end up having to replace it anyway. Or you get bogged down maintaining and integrating with an overly complex system.

Re: Software engineering topics I changed my mind on

#470

Post by joatmon-snoo » Sun, Jan 24, 2021, 1:26 PM UTC

austincheney wrote: post #179

H8crilA wrote: post #104

Earlier quoted context omitted.

It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.

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? You Betcha.)

* "Oh, I'll just roll my own fake of Foo" - congratulations, now anyone looking for a fake needs too decide between yours and the other one. (Yes, this is highly context dependent, but the moment you have multiple fakes in common/util libraries this usually starts being a problem.)

* "I can just use raw DB writes for this, because I don't want to learn how to use this API" - except the abstraction exists because it guarantees you can do safe incremental, gradual pushes and roll back the change, whereas your home-rolled implementation had a small bug and now the oncaller needs to do manual, error-prone surgery on the backup instead of the usual undo button built into the API. (Oh, and legal is going to have a field day because there's no audit record of the raw writes' content.)

Cargo-culting is bad, yes, but reusing existing abstractions is often important because they handle (or force you to handle) the various edge cases that someone learned about the hard way.

And of course, if you find a bug in the existing abstraction, well, congratulations- you just found a repro and root cause for that infamous support case that's been giving everyone data integrity nightmares for months.