Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

201–210 of 369 posts

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

#201

Earlier quoted context omitted.

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…

> 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…

Most companies already have the "apprenticeship" half-codified in "Junior Developer" versus "Senior Developer" distinctions or "Level Ranks" or other ladders like that. If you switch jobs mid-"apprenticeship" today in the software industry depending on who you interview with and how well you can negotiate you either "start over" at a low rank/level/job title or luck/bs into "skipping that step" and jumping to a higher rank/level/job. Standardizing that across the industry wouldn't necessarily be a bad thing for the industry.

Similarly, PE licenses would be so hugely worth it to the industry if it saved everyone time in "technical interviews", both interviewees and interviewers alike. How many collective labor hours as an industry are we wasting annually on "technical interviews"? For most classic Civil Engineering firms the "technical" part of the interview is almost entirely "Is your PE license valid and up to date?" "Yes." "Great, you're hired." The software industry would rather waste multiple hours (if not entire days) of wages of everyone involved instead, and it's rather sad when you think about it.

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

#202
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 believe I heard this in the Pragmatic Programmer: engineering is the practice of applying scientific understanding to real world problems. Or more succinctly, engineering is applied science. So software engineering is applying computer science to solve real world problems.

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

#203
post #129

Earlier quoted context omitted.

I believe that Shopify will change your job title from Engineer to Engineering Technician (or something of that nature) if you don't have your professional engineering certification.

At Shopify I've worked with people with pinky rings and they are still called developers :)

A pinky ring and a P.Eng signify very different things. In Canada some of (all of) the accreditation groups are very sticky about who is called an "Engineer", regardless of degrees you have or don't.

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

#204
post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

> 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 possibly including embedded/safety-critical development and emulators).

When experienced programmers utilize global variables whenever it makes sense, it tends to bite future generations. Windows's GetLastError is a mess (some functions set it on error but don't clear it on success), I'm not sure about POSIX's errno, and when threads were introduced, these variables had to be changed to thread-local state.

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

#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.

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

#206
post #162

Earlier quoted context omitted.

> Getters and Setters? You probably don't need them. Classes can have public member variables. The getter / setter debate and public fields is about exposing the internal implementation of the object (and thus making it unchangeable without breaking other code) and being able to reason about where the internals are used (if you do need to change them). For example, if I've got a java.util.Date exposed as a public fie…

Apparently your field was used both for some internal shenanigans as well as a public field through the get/set indirection. Then you changed the field but kept the old public behavior. I wonder whether (1) that dual purpose internal/public role was wise to be begin with, and (2) whether that change of the internal logic of the getter might have just papered over a more significant change. It might be good if a chang…

The backing implementation of what supplies the DTO shouldn't be an issue for the client / other part of the application if the contract that the DTO provides remains the same.

If that contract is the underlying field implementation, then that means that those fields are frozen and cannot change.

If that contract is instead methods, the underlying field types can change (for example from a Date to a LocalDateTime) while the method contracts remain the same and new method contracts are added to expose more functionality for other clients / application modules.

In particular, this was code written in the Java 1.7 days and it was Date (and all the mess with java.util.Date and java.sql.Date) while in 1.8 java.time was provided which allowed the underlying implementation of the object to cleaned up without changing the contract of the methods (things wanting a Date still get a Date).

Yes, changing from a Date to a Calendar (because of the aforementioned java.sql.Date mess) to a LocalDateTime were significant changes -- but the clients didn't notice because the methods they were using remained consistent.

The deeper you expose the client contract into the guts of the object, the more difficult it is to change when a change is needed.

Now, if you're just passing DTOs around between classes within a single package or local to one library that don't leak - feel free to do whatever is needed. I suspect that records will solve a lot of the boilerplate DTO code, though passing a record outside of a library boundary gives me a bit of unease because it means that changes to the record will be breaking changes to the clients.

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

#207

Earlier quoted context omitted.

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…

> 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 enrolled in computer science majors where I graduated put forth.

Again, the American perspective is useful. I had no idea you would be bound to one employer during the apprenticeship process. In Canada, employees are free to move around.

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

#208
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…

Yes, I think we sometimes use the term "Engineer" a little too liberally in the US. For example, sometimes the janitor of an office building is called a "Custodial Engineer" which often just gets shortened to "Engineer". I remember the first time I heard a coworker say, "I'll call the engineer to have the thermostat adjusted". I thought that was overkill, but then a guy in overalls showed up and it made a little more…

Was your colleague from the UK? A number of trade professions in the UK are referred to as Engineers, such as for the boiler etc.

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

#210
post #110

Eh, kinda. Calling something a "best practice" is basically an appeal to authority. It means, "this is the right way to do things, for reasons I don't have time to explain." There are times when that's appropriate. But really, "best" and "right" are highly situational. Any rule of thumb, even the most basic and uncontroversial, has a situation where it doesn't apply. I was part of a discussion on a mailing list years…

> 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?
Post reply on HN