I'm not a coder, or a programmer. I'm a problem solver, and I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code. If you think of yourself as a problem solver first and foremost, then you'll often realise that the best solution involves zero code.
This ${problem}-solver versus ${solution}-user gets even worse when people go beyond define themselves as technology-du-jour users, doesn't matter if it's Rails, React, blockchains, big data, ML, AI...
1. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
"I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms"
"I'm a problem solver, I make sure the books are correct at the end of the financial year"
etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are doing each day even if the value they create and what they are working on can be wildly different. Just like a deep sea welder.
In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibilities, where writer and programmer both talk just about primary means of achieving the job, and coder/typist bring it down to the mechanical skills you require to get the job done.
We are not engineers. We have no standardized certification process or tests. We have no (or very little) accountability. We have no codes of ethics. We may or may not be following proper, accepted development workflows. We may not even know what industry standard processes are.
I am a software developer because I solve problems primarily via software. This can and does include many different responsibilities and skillsets, but at the end of the day I primarily architect and write code.
It's up to you to educate the layperson as to what a software developer actually does. Although I'm not a writer, I understand that a "writer" doesn't literally only write. People can understand better than you're giving them credit for, I think.
that's your definition of engineering, or whatever officials that define it
more so, who cares about your skills other than your employer? And your employer cares about your skills, why should he care about your title?
even if other programmers who like to address themselves as software engineers, is it up to you to decide whether they can be hired?
It's just a title for god's sake
I would like to see the status quo changed, which is why I do discuss it. Of course it's fair that I hold an opinion and discuss it. There is no obligation for you to respond if you disagree :-)
> that's your definition of engineering, or whatever officials that define it
It's not my sole opinion:
> As with many other professions, the professional status and the actual practice of professional engineering is legally defined and protected by law in some jurisdictions. [3]
It's understood that if someone holds the title 'Engineer', they went through a certification process from a regulated body, traditionally. You can see this for example in countries and per state. [0] [1] [2]
> In Canada the designation "professional engineer" can only be used by licensed engineers and the practice of engineering is protected in law and strictly enforced in all provinces. [3]
In Canada (and I believe some states), it is illegal to sign off an email or other correspondence as a "Professional Engineer" if you're not actually licensed as such. [4]
---
> is it up to you to decide whether they can be hired?
When did I mention hiring? All I said was the term 'engineer' is loosely used in the software industry, and it has absolutely no standard around it.
> employer [...] why should he care about your title?
I wasn't talking about my employer at all. I only referenced skills because I was responding to a portion of the parent comment.
> It's just a title for god's sake
It isn't. How we frame something is very important in my opinion–just as important as the concept itself. [5] If it's "just a title", then people should have no problem calling themselves programmers or developers. However one can see that we call ourselves "engineers" because it sounds prestigious, despite the software industry being a total joke when it comes to standardization or even following basic modern practices consistently.
[0]: https://engineerscanada.ca/accreditation/about-accreditation
[1]: https://ncees.org/engineering/
[3]: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
[4]: http://www.occupationalhealthandsafetylaw.com/ontario-man-fi...
[5]: Consider for a moment the term "Global Warming" versus "Global Pollution Epidemic". I strongly believe if we had gone with the latter instead of the former, there would not have been pushback to the scale that we've seen. It certainly would have avoided the confusion of "oh, but this winter is so cold, global warming must be a hoax"! It also shifts the focus from an effect of pollution, to the pollution itself. This example is quite different than the software engineer/developer example, but I think it illustrates my point that how things are framed is very important.
We are not software engineers, and we won't be until regulatory bodies exist, and we develop codes of ethics.
Nobody said that you are software engineer, you can just call yourself whatever you want
Those who called themselves software engineers are indeed software engineers, no one can forbids it
Fancy term like engineer is for marketing purposes, just like you said it's prestigious, they use it because they want to impress people, anything wrong with that? No, it's correct.
And it's also correct if anyone think they don't fit the title engineer, because it's his/her opinion which the software engineers won't likely give a fuck.
No one can stop them from using the term.
As for the Canada's law, the earth is bigger than that AFAIK. China and US software engineers are waiting for arrest. Except for Texas FYI
Standardization/basic practices mean shits by the way, it's research and development phases during engineering, people can invent what they want in their own ways as long as their products are legit
From Wikipedia:
> Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
Wikipedia can be sue at anytime, as you like
I think you're misinterpreting the intention of the title of "Professional Engineer". As far as I can tell, it's for accountability for public projects (buildings, power, etc.). It's not strictly limiting what job titles can have the word "engineer" in it.
Most engineers in the aerospace industry don't even take the FE exam. Would you refuse to call most aerospace engineers "engineers" then?
Requirements are pretty high: http://www.peo.on.ca/index.php/ci_id/2057/la_id/1.htm
But I suppose industry/capitalism loves the fact that we don't require licensing in order to produce software even if use of said software should be safeguarding health, property, economic interests, etc.
In both of these situations they're a programmer, but they sound cooler and will go a lot farther when applying for jobs or moving up in a company than the person who labels themselves as "a programmer".
At the same time, you have to actually describe your profession somehow. Everyone solves problems. Solving problems is definition of productive work. A carpenter solves problems by cutting pieces of wood apart and attaching them together. A bricklayer solves problems by stacking bricks on top of each other, with a bit of mortar in between to smooth them out. A car mechanic solves problems by fixing cars. A surgeon solves problems by cutting people open and fixing their insides. Eventually it turns into a bunch of meaningless MBA platitudes. "We don't 'build houses', we 'deliver solutions' to people's shelter-related problems."
If you go to a good surgeon with a problem that isn't going to be fixed with surgery, the surgeon is going to recommend a different solution and possibly even refer you to a different kind of professional. "Hey, you just need to rest that knee and maybe get some physical therapy. Here's a physical therapist I recommend." People understand that surgeons are smart and will occasionally listen to them, so surgeons can get away with this. More importantly, surgeons understand this. Surgeons don't go around thinking, "man, I need to perform even more surgeries because I'm a surgeon and that's what surgeons do" (or, at least, they shouldn't)--they have a deep appreciation of what surgery is and when it is or is not appropriate.
So I don't mind thinking of myself as a programmer, because I'm a programmer the same way a surgeon is a surgeon. If you come to me with a problem that cannot be solved by programming, I will tell you that, because to do otherwise would be a form of malpractice.
Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.
If you’re doing that you’re an engineer. Hopefully we are all doing that.
Of course, there is something in the middle, and for software, that is probably “coders” or “programmers”.
The big thing is that you need a P.E. in many cases to do things like sign off on drawings for regulators. Some civil engineers, mechanical engineers, etc. have PE's and many don't. In Louisiana, I had business cards with an engineering title and definitely worked as an engineer. At some point, had I remained in the oil business, I'd have gotten a PE because I'd presumably have eventually been in a position where I had approval authority over designs submitted to various government agencies.
ADDED: TIL apparently Texas is indeed exceptionally restrictive (in theory) about the use of the term "engineer." [1] I'd be pretty certain this is widely ignored in practice. Leave the oil business aside, I'm guessing that tech companies in Texas probably advertise engineering positions now and then. (Yep: https://jobs.dell.com/location/united-states-texas-round-roc...)
[1] https://www.statesman.com/news/20160903/their-name-on-the-li...
Go look into the actual law, you legally can't call yourself an engineer in Texas without a PE, or a couple tiny carveouts (on the order of you work at NASA, and NASA calls you an engineer)
There are doubtless tens of thousands of Texas job listings for "engineer" positions in software and elsewhere. (Software is especially notable only because my understanding is that PE's in software have basically been phased out. So you basically can't get licensed in that branch of engineering even if you have an accredited degree and have met the other requirements.)
You can do engineering without following any official standard, and anyone who do engineering is of course an engineer, so yeah, the protected title thing is just meh.
I guess because I don't like any of the established terms.
Would be nice if there was a word that captures the idea of someone both designing and constructing the internals of a machine.
Source: https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...
The issue is that the problems that Bitcoin and Ethereum are trying to solve imply almost generating money from thin air. That gave unscrupulous people a lot of silly ideas, on the one hand, and, on the other, gave the people desperate to prove they're "thought leaders" (whatever that means) a lot of different, but still silly, ideas.
it's time for you guys to realize this effect from calling yourself "coders"/"programmers"/"problem solvers" are nothing but marketing
It's just to impress those who don't know otherwise
So basically a coder?
Code has to be maintained, or it will eventually fail as other moving parts around it change their interfaces.
Code rots. Platform norms are always changing, so today's fresh new code becomes tomorrow's smelly old code.
Code interacts with other code. As the volume of code increases linearly, the number of these interactions increases exponentially. Eventually the complexity becomes unmanageable and the whole system has to be rebuilt. The more code you add to a system, the faster you hasten its demise.
All of which means that code is a liability, in the balance-sheet sense of the term. Throwing code at a business problem hurts the bottom line. The goal therefore becomes to throw just enough code at the problem to solve it, and not one line more than that.
This is the difference between inexperienced and experienced developers. Inexperienced developers handle code like it's spackle. Experienced ones handle it like it's uranium.
All code we write is going to be wrong in some way as a result of our understanding of the problem domain being incomplete so I'd rather see code with an obvious place to put an if statement than a lovingly constructed masterpiece of indirection and abstraction.
Obviously there are basic rules to follow, make it testable, don't mix too many concerns in one place but I see so much bikeshedding and overcomplicated code when it just needs to not be obviously wrong and easy to replace when needed.
Somewhere there is a balance, but for business purposes it leans closer to the "working ugly hack" side.
There is no next release, maintenance, new features etc. Once Balloon Pirates is done it ships, and is never touched again.
There is also the side issue of game engines which many teams reuse from game to game so maybe that doesn't really apply.
One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on.
Unless you have written (and debugged!) an actual video game, you should spare your judgement.
But Modders also have a hard time adding features if logic for all items is in a single function. This seemed exactly what OOP / interfaces were designed for.
Also I'd love to see Terraria's actual source code. The de-compiled versions hat a ton of stuff like
> if (num1 != 109 && num1 != 110 && (num1 != 113 && num1 != 115) && (num1 != 116 && num1 != 117 && num1 != 118)) return;
or
> else if ((int) Main.tile[i, j].type == 19) Type = 94;
20x in a row, with obviously different numbers. Hope the actual code was more readable and just lost a lot in translation. But many more readable styles should be visible in IL (enums, constants, etc). There might also have been some obfuscation (can't remember), but couldn't have a strong one since names were preserved.
But yes, there are also advantages to their style of code. And in the end they delivered a product and that's all that counts.
Rules engines, statecharts and other forms of (declarative) behaviour modelling solve real problems.
[0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take responsibility for problems when they arise. Another instance of worse is better.
But it solves the problem users want solved. It's lego-level blog assembly, which is as technical as many users want to get. A much "better" system - maybe a nice type-safe Haskell static HTML templater with a command line build system - wouldn't.
Flipping this around, from the user's POV, "I wrote some code that almost does Thing X" is not a solution - it's just some code that doesn't quite do the job.
It's nice that it uses functional programming or formal methods or $shiny_language or ML or whatever. But if it doesn't do the job, it doesn't solve the problem.
never again.
Yes, there's backwards compatibility to maintain, but surely some of it can be contained, maybe with shims, like Windows does it.
In all likelihood, because the people maintaining Wordpress are the people who created it in the first place, and they don't know any better.
Why did PHP apps suffer from SQL injection attacks, long after PHP supported prepared statements? Why do Java apps often have ridiculous classes like AbstractSingletonThingFactoryFactory? Why does the Javascript community (still) promulgate useless leftpad-like packages? Why do Ruby apps often end up so heavily metaprogrammed that you can't trust any line of code to do what it says?
Cultures are hard to change. The people that are turned off by Wordpress' programming style probably pick other projects and other communities. Lots of the folks working on Wordpress probably cut their teeth in that codebase. They might not like it and they might realize there are better ways, but there probably isn't a critical mass of them that share a vision out of the morass.
Personally, I took one brief look under the covers of Wordpress and immediately decided to avoid it.
https://old.reddit.com/r/webdev/comments/bx51vk/we_need_to_t...
I was expecting to see some ill-advised use of WordPress in a critical software system, but no, it's about inconveniencing web developers. </rant>
That's what I think of when I hear technical debt.
What are examples that make sense and don't just explode in your face?
In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.
Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.
The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.
I don't think it's the type of debt that's the issue, as much as how you manage it.
I hate this term, because worse isn't better, it's worse. But good enough is good enough and technically-better-but-not-available-yet is worse than adequate-and-available-right-now.
If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way nebulous or changing, well architected software will save you a lot of money responding to changes, and ongoing maintenance will obviously be cheaper if it's easily testable and robust.
But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.
The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.
Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.
Or they're a pro in a very different field than you.
When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different.
I imagine a NASA engineer creating famously low-defect code or perhaps an engineer creating control systems for a nuclear power plant would similarly look at our medical code and think we too ship far too many hacks and defects.
Being a professional is knowing how to do your job well. Applying a single heuristic to every problem isn't that.
> Applying a single heuristic to every problem isn't that.
How ironic :)
And about that implied ad hominem. It doesn’t matter if I’m a pro.
Building codes allow one to say whether plans conform or do not conform to code. That way you don’t have to be a “pro” to determine whether the plan is up to code. You compare the plan to the code. You didn’t write the code. You don’t need to think the code describes beautiful plans. You just compare.
There is quality in code which you seem to be ignoring, troubling.
There is quality in delivering on time.
There is quality in the end-users' experience.
There is quality in the developers' experience.
There is quality in the investors' experience.
Quality is different than maximizing a metric (earnings per share, on time deliveries, user experience survey score, code coverage)
There is quality in finding the right balance in any situation.
Many many people want to maximize a single metric tacitly expecting everything else to be great, that is a good lesson to unlearn. Switching from one quality target to another is not.
If the business problem is complicated, trying to further simplify the code usually makes it awkwardly abstracted and extra brittle. The fix should not be _just_ cleaning up the code, but rather trying to resolve the original usecase.
Yes if you boil it down to it’s essentials you are right the customer is the one with the money, so satisfying his needs/desires is what matters.
But, and thats a big but, we as devs are also humans, we also have desires and needs, and in the long run companies that successfully balance the needs of its users with the needs of its workforce get the best workers, which solve the problems of their users better/cheaper/faster.
So it’s more of an equilibrium kinda thing. If you stray too much in any direction the organization tanks - either the users loose faith, or the people satisfying theirs needs do, which leads to failure just as much.
The complexity with balancing this usually stems from the fact that both of those variables are subjective to their respective environment - users can tolerate bad solutions if there are no alternatives available, same with devs.
And that is also a subject to information availability - devs can be ok with their situation because they don’t know what salaries are at that other place for example.
Can we stop with these simplistic maxims? Engineering is about tradeoffs and dealing with complexity. Trying to reduce the decision-making process to a single sentence is silly.
Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder why things get completed on time, why bugs happen, why sites get hacked etc.
Somebody else has mentioned this analogy before in this thread, but if you had a house built would you say the same thing about the structural integrity? "As long as the floor can support me then thats all that matters", "House dwellers don't care what kind of structural beams are used to support the floor they just want it to not collapse". That kind of a mentality is ok for an average person living in a house but you'd you have to be off your rocker to hire a building manager who said that.
I interned at a research facility where I had to figured out obscure serial commands for a two axis objective stage, interface microscope camera, and image analysis. Then I wrapped it all in a python library for them to use.
From my mentors perspective however, the goal was “simple”: you find a microorganism swimming under microscope, and keep following it to record its trajectory. Make sure each tick is max 10ms because those little ones move FAST. They didn’t care if I used 4 space indents or 2. They cared about getting pandas dataframe so they could do all the analysis.
I can’t explain this in a word or few, and I still don’t know what to call myself! Am I a developer? I don’t know.
I would say the title "Research Engineer" could fit quite well based on what you describe!
It does if you want someone other than the person who wrote it to be able to fix bugs and add features.
The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC
If your code quality is bad, you can't do that efficiently. Your developers will hate their jobs and churn like crazy.
And by "bad quality" I don't mean "not unit tested" or "not commented" or "poorly formatted". I'm talking about code that is difficult to reason about, difficult to debug and difficult to refactor or extend. This is hard to quantify or even verbalize. It has to be felt.
To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for.
And to the company we work for, what matters is that we solve the end user's problem, and that we do so in an expedient and economical manner, so that it costs less for us to do so than the customer pays us.
Of course, for us to continue doing this, in the long term, we need to innovate and architect and uphold standards and stay on top of technical debt. And all of that put together is "make the code good". But that's an end to the means, and the customer doesn't care what horrors awake when they click that dialog box button as long as the result they needed pops out at the end.