Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

211–220 of 369 posts

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

#211
post #205
post #60

> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…

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 better than we do. For every Google there's a Ford, and for every scrappy startup there's a scrappy machine shop.

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

#213

Earlier quoted context omitted.

> somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost…

But here's the thing: aren't most alternatives to global, some other kind of global state anyway, but possibly better managed?

Singletons come to mind as being a better alternative in languages that can do that sort of thing.

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

#215

Earlier quoted context omitted.

> So why is there so much resistance? Because, 1) a PE license is useless for software/computer engineering. 2) the FE exam covers a bunch of irrelevant material. 3) once you pass the FE exam, there's no real mechanism to advance because there are no apprenticeships available in computer engineering. And you can't take the PE exam without the apprenticeship. My college spent a lot of money getting an ABET accreditati…

Thanks for providing the US PE perspective. There are definitely people practicing as PEngs and apprenticing as EITs up in Canada under both the software engineering and computer engineering disciplines. So there is some value up here to those. Undergrad covers irrelevant material such as humanities, social sciences, and communication that add cost and time to an education. Or at least that's the argument people enro…

> In Canada, employees are free to move around.

I think you can here as well, but the problem is finding an apprentice program in Computer & Electrical engineering is next to impossible. My school had one option for people looking for an apprenticeship. It might be better elsewhere in the country.

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

#216
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?

We are the actual Engineers. For US-Based IT workers, that means a degree from an ABET [1] backed institution with a traditional undergrad and graduate programs.

Anyone else calling themselves an "engineer" while doing IT work are not.

In addition: Readers need to remember this isn't reddit and downvoting comments with facts you do not like is not appropriate for Hacker News. It's is depressing this reminder needs to be added here for facts as it appears a few readers here have forgotten already.

[1] https://www.abet.org/

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

#217
"best practices" = "common practices" in practice.

Not necessarily best. Best practices you get when you apply a darwinian approach in your org and try out several techniques before selecting the best. What is called best practices too often is a name for "we've done it this way since the beginning".

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

#218

Earlier quoted context omitted.

> somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost…

But here's the thing: aren't most alternatives to global, some other kind of global state anyway, but possibly better managed?

Almost assuredly better managed. There are no reasons to manage state on the global level apart from laziness.

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

#219
post #60

> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? We call ourselves software developers in Canada. According to Canadian engineering[1]: The "practice of engineering" means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising, or managing any of the foregoing, that…

I write server-side software for a security system - anyone else can write a similarly complex piece of software to monitor grains of sand on the beach. So I am an engineer and they are not just because my software is used by some pre-described group of people?

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

#220

Earlier quoted context omitted.

> somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost…

Global mutable variables are generally a bad idea because they have nonlocal side effects which are difficult to mitigate, like aliased mutable pointers but worse. Extra non-aliasing arguments and multiple return values are free of these issues, and a better tradeoff in almost all cases (unless you're sure you'll never run 2 instances of a system in the same address space, and you have specialized constraints possibl…

> When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations.

Usually.

There is one pattern I keep using in Rails to inject the current_user for the request into the model layer. At the beginning of a request, Thread.current[:current_user] gets set to the current_user. At the end of the request, it's cleared.

For those unfamiliar, each Thread has its own Hash object and [] and []= instance methods to access it. It's a way to create global variables scoped to the current thread. To hide this implementation detail, I wrap this functionality in ApplicationRecord.current_user and ApplicationRecord.current_user= methods so no one accidentally uses :curent_user.

The most common use case for this is to automatically set created_by and updated_by on a model, the same way created_at and updated_at are set.

Cron jobs can do something like ApplicationRecord.current_user = User.cron_user if needed. Ideally, I would set this in a CronTask parent class so current_user is always available in the model layer.

I always document these methods and explain exactly what is happening and why. Abstracting away from the implementation detail mitigates most of the problems with a global variable. Obviously, the Thread.current method does not work at all if you're using an event or actor driven architecture. Rails does a thread (or process) per request, so this works extremely well.

Post reply on HN