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…
Are software engineering “best practices” just developer preferences?
301–310 of 369 posts
Re: Are software engineering “best practices” just developer preferences?
#302Earlier 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…
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?
#303Reason 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?
#304Earlier 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…
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> 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…
Re: Are software engineering “best practices” just developer preferences?
#306There 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?
#307The 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…
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?
#308Re: Are software engineering “best practices” just developer preferences?
#309Best 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…
Which is to say, early ecosystems in Java certainly needed this criticism. They did adjust, though.