25 comments

[ 4.6 ms ] story [ 57.6 ms ] thread
> I then created a new repository on GitHub and created my own network scanner for iOS called MMLanScan (The reason I didn’t create a pull request back to original project it’s because it was abandoned).

This seems a bit like his early attempts to sell free Ubuntu discs. Hopefully he got the wording slightly wrong and forked it instead of starting a brand new repository with no attribution.

That was fascinating, but I don't quite see the application here.
If what the grandparent comment pointed out was deliberate rather than a goof by a inexperienced developer, then it steps right into the sociopath box.

And frankly the article is so relevant to current goings on in the FOSS world that it hurts reading it.

Not sure what's wrong with selling Ubuntu disks.

Initially, Stallman made a living selling GNU tapes, and pre-Internet, linux was often installed by a "friend" who made the stack of 40 floppies and charged a few bucks to cover his time and media expenses.

Slightly off topic but one thing I've long been curious about is what are the requirements to call yourself 'software engineer' as a job title?

In many parts of the world claiming to be an engineer (in a professional capacity) without the required qualifications opens you (and your employer) up to all sorts of liability issues.

I am a Materials Engineer I've long suspected the software engineer title is not regulated anywhere near as heavily.

AFAIK, it's not regulated at all - certainly nowhere in the US that I've lived.

But... I don't call myself a materials engineer, which probably has some sort of licensing or regulation, no?

It was more of a curiosity mostly centered around liability. I was curious for example what happens if you write a piece of safety critical software and it fails. Can you be found at fault as the author? Where does the responsibility lie is it with your employer who hired you on the presumption of qualifications?
>who hired you on the presumption of qualifications?

This whole line of thinking doesn't really apply to software development. Formal qualifications are, at best, only required to get you a first interview. Formal software development qualifications are generally regarded as being only tangentially related to the ability to do the job.

How do companies avoid being found negligent i.e. Could a company be sued for hiring someone grossly incompetent on the basis they did not vet the employees competence?

I'd always presumed there were similar requirements (i.e open source licenses often disclaim liability for code released under them)

(comment deleted)
>Could a company be sued for hiring someone grossly incompetent on the basis they did not vet the employees competence?

Not sure. I have personally never heard of it but that is hardly conclusive.

Its not the kind of job where individuals are out making decisions on their own as a rule. Particularly at established companies people's work likely has to pass assorted automated tests and rounds of human review and testing. And then the companies software is wrapped in extremely carefully worded licences and contracts to limit liability.

Also bear in mind that software is typically produced behind closed doors. The external users of the software likely have no idea as to the identities of the humans producing the software they use. You would never know if someone incompetent was hired (assuming their poor quality work somehow got released) because you don't know if the software is being produced by 1 or 100 humans.

Because noone knows how to vet effectively. And we still have no idea what "being a software engineer" mean.
Disclaimer: IANAL.

Most licenses disclaim liability.

99% of all software comes with an end-user license agreement saying “we aren’t liable for anything that’s gonna happen to you because of our software”. Also, EULAs sometimes (like in MS Windows) forbid usage of the software in safety-critical applications, defined as “device or system in which a malfunction of the software would result in foreseeable risk of injury or death to any person”

Other 1% of the software, legal teams underperformed and were unable to press public enough to accept similar agreements. So, in automotive, avionics and especially medical devices, users sometimes indeed sue manufacturers over faulty software. However, I’ve never heard about a process for hiring someone incompetent. People usually bring claims against companies for making a defective product, asking for compensation.

(comment deleted)
When I'm wearing my work hat, I'm a "Senior Security Software Engineer". It's a title given to me by HR to identify my role at the company, not a statement about my training. In fact I'm self-taught and have no degree.
The title software engineer is not a claim to be an engineer, anymore than software architect is a claim to be an architect.
It's certainly regulated in some places, Iceland for example, and in the UK there would often be the assumption - though probably not the legal requirement - that you'd taken a degree that has been granted accredited status by the national Engineering Council.

[1] https://en.wikipedia.org/wiki/Software_engineer#Regulatory_c...

Its for the degree reason I call myself a programmer not a software engineer.

I'm better than lots of people I've met with the degree but I don't want people to infer that I have a degree from that convention.

I think the fact that Software Engineering not being regulated has been offset by the fact that the concept of open source code and open information (relative to other branches of engineering) pushes good practices to pretty much every programmer on the planet without asking (most of the time) and peer pressure is heavily against anyone who tries to sneak away or laze. I think software engineering is unique in being a collective of uncoordinated knowledge that self-heals and self-optimizes. All thanks to the open source movement and the n-number of tutorials online.
The biggest barrier of contributing back is that it takes a lot of time and effort (even for small projects) which you are not obliged to make. A lot of the time the driver for contribution is only the person's internal belief that he/she has to do it and honestly sometimes even when you want to contribute back, you don't have enough time or energy after 8+ hours of work.

It can be a big difference if the library author allows contributions much-much easier to make.

Some open source projects have "Easy to Fix" issues to get people on the roll (like Scikit-Learn), but many don't.

Some have overview of their source code and their design principles (like Redis) but many don't.

Some have good documentation of how to get your patches in main tree but many (especially those not hosted on github) don't have it.

Most notably for C/C++ projects, the undocumented dependencies to build the library can waste hours at a time.

Open source is great (I have contributed to a couple of projects) but not all projects are equal in terms of quality/easy-to-hack.

Brad Fitzpatrick has also written quite a bit about this http://brad.livejournal.com/2409049.html

I learned a lot about what I was lacking or what was expected of me in early interviews, it's as if we need a few more blogs like this and some transcribed interviews to prepare people for those "oh shoot I forgot to learn something simple" moments. It's going to happen for college kids and self thought no matter what. If this were a intern job he would have still gotten it and been trained on git. The OS X time machine reply is priceless though...I can remember the copy a folder for backup every hour programming days...horrible times:)