Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

301–310 of 369 posts

Re: Are software engineering “best practices” just developer preferences?

#301
post #112

Earlier quoted context omitted.

Some of us call ourselves "engineers". It just depends whether you want to pay the order for the privilege of having the title (and pretty much no other tangible benefit in 90+% of cases) :).

Genuine question. What is so important about the word "engineer" that people not licensed to practice it want to call themselves engineer? In Canada, I studied in a mechanical engineering technology program that lead to an engineering degree if you stayed on for 4 years. It was hammered into us that we weren't engineers until after you graduated and went through the professional licensing process. In Canada there is…

Because some people here are hiring people they need to work for less money.

Re: Are software engineering “best practices” just developer preferences?

#302

Earlier quoted context omitted.

Same with Clean Code, SOLID, DD SOLID is especially funny because majority of developers doesn't understand / can explain it, let alone have read papers e.g [0], except maybe S letter, yet everybody acts like they do SOLID*. Or Clean Code's small function craziness or misinterpretation and going into "avoid comments" approach * - unless you ask for details [0] - https://www.cs.cmu.edu/~wing/publications/LiskovWing94.…

So the only caveat I would put on that: it's useful to have common language for things, my threshold is that you understand why things are this way. It's useful to tell someone: "you should have that thing in another class because it's clearly another responsibility", and have a debate on the responsibility itself ; or even on the merits of having a single responsibility per class. What is not useful is when someone…

Or, common language comes with some assumptions.

Lots of people in software use lots of marketing terms as descriptions of the practice of their work. This is the crux of this conversation, actually: that absent "best practices" rooted in enforced standards, they're all really just marketing terms until proven otherwise.

Re: Are software engineering “best practices” just developer preferences?

#303
> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The interfaces weren’t extended by multiple classes, this wasn’t an external library or a dependant, and there were no plans to implement additional classes later.

Reason I avoid working in Java and especially the "senior java engineers".

> The logic from the senior engineer was that the interface represented the “contract” and the class the business logic.

This is basically religious dogma

Re: Are software engineering “best practices” just developer preferences?

#304
post #205

Earlier quoted context omitted.

I aggressively refuse to call myself an engineer. Programmer is fine. Developer is better, because programming is only a piece of it. Y’all can call yourselves whatever you like, but inside I’m thinking you retconned an industry insider euphemism into a non-existent sub-type of engineering, by protesting all the ways you apply rigor to what we do.

What of those who graduated from engineering programs taught at engineer colleges? Lots of people in other engineering disciplines build stuff with less rigor than is used to build software. Maybe load test it in Fusion 360 before sending the file to be milled. And lots of software companies test their stuff quite rigorously. People who write software have imposter syndrome. Other disciplines are not building things…

> What of those who graduated from engineering programs taught at engineer colleges?

For new grads? In my experience, they're usually miles behind an 18 year old who has been messing around in their spare time for a few years. There are, of course, exceptions, but at this point seeing something they don't teach at the local universities is more eye-catching on a resume than most degrees.

It usually means they bothered to learn something on their own.

Re: Are software engineering “best practices” just developer preferences?

#305
post #303

> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The interfaces weren’t extended by multiple classes, this wasn’t an external library or a dependant, and there were no plans to implement additional classes later. Reason I avoid working in Java and especially the "senior j…

I am doing this and it helps in mocking the interface in other classes tests.

Re: Are software engineering “best practices” just developer preferences?

#306
I had a principal engineer who wouldn’t use the term “best practices”. Instead, he called them “proven practices.” I’ve adopted that term myself, because it is much more accurate- there is a body of knowledge on how to build software well, but it’s a tool kit not an instruction manual.

There also really is software engineering that goes on- I work in an org that does extensive analysis, testing, and validation of firmware before it is rolled out. It’s a real thing. That being said, so is cranking out a CRUD web app with zero testing to make our PMs data collection tasks easier. It’s all on a continuum. The key trick for software “engineering” versus just development is knowing where in the continuum a given project needs to be and what tools are appropriate in that context.

Re: Are software engineering “best practices” just developer preferences?

#307

The biggest issue I saw with "best practices" in my career is the failure to take into account who it claiming it to be a best practice, and in what context . I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand. Or alternatively, believe…

To add on to this, the current most preached about "best practices" comes largely from a de-risking, never-ever fail point of view, ie. 'safety'. Unfortunately with such standards also comes a concept known as 'acccountability', ie. 'ass-covering' practices that provide little practical value.

This results in programmers no longer being able to iterate fast and having to rely on some third-party whose tradeoffs they don't understand, resulting in slow, bloated software and dissatisfied programmers.

Re: Are software engineering “best practices” just developer preferences?

#309
There are people on both side arguing that "best practices" are good and bad. But that's not the point.

Best practices are necessary. The value of "best practices" rests not on whether it is good. Its value is that there is an enforced standard across a business/organization. The existence of a standard (and recommended way) helps smooth out the execution/operation. In software engineering, that means easier refactoring, easier migration, easier tooling development, easier training, easier for people to move around within an organization instead of moving out...

I'd recommend any organization to find, install and periodically improve their "best practices". Just the virtue of their existence is a net positive to the business.

Re: Are software engineering “best practices” just developer preferences?

#310

> Java is infamous for its verbosity. [...] This paragraph highlights something I've been saying for ages. Most criticism of Java needs to be directed towards Java programmers and not the language itself. The language allows you to simply make a class. You're not required to make an interface and then make a class that implements it, and yet, Java programmers do it anyways and then criticize the language for being ve…

Amusingly, j2ee did require you to make an interface and an implementation. I seem to recall you had to also have a "stub" class.

Which is to say, early ecosystems in Java certainly needed this criticism. They did adjust, though.

Post reply on HN