Over the past 4 months or so I've been trying to define what exactly are some of the differences in expectations for tech folks from three backgrounds: self-taught, those with a formal education in Computer Science, and those trained in Software Engineering. I would really like your opinions on what you expect from yourself and what you expect from others.
My intent is to try and get a clear idea over the next 6 months and write about it, and each year following I'd like to do an update. In a way, it'll be tracking their evolution.
I'm going to be intentionally vague here because I don't want to lead the conversation but it's my position that the tech industry is a bit of a 'wild west' right now. It's not really clear who can do what, and resumes and interviews can be extremely difficult for figuring out what a candidate can actually do. I'm also coming from a Canadian perspective, where the term 'Software Engineer' is protected so someone can't willy nilly just title themselves an Engineer on their projects.
Looking to web development, I believe that a self-taught developer could certainly teach themselves everything about solid and robust system designs and learn the mathematical foundations that students need to take in formal education. Similarly, someone from computer science could mold their degree to be strictly theoretical (i.e., for masters and doctorate programs later on), or train for more direct application like an engineer must. Finally, someone from software engineering could go on to purely "engineer" software, or perhaps they could go into more of a managerial position, or just stick to pure development. The point is that anyone can learn what they need and be excellent at it. So how can you possibly have any sort of expectations?
I am in no way intending to imply a hierarchy. Instead, I'm trying to build a venn diagram of where these trainings are the same and where they're different. Your thoughts would be greatly appreciated, and may be quoted in future blog posts either here on Dev.to or my personal blog site.
Credit to Luis Llerena for the cover image. Image found on Unsplash here.
Top comments (32)
Check out a book by Pete McBreen called Software Craftsmanship: The New Imperative. It does a wonderful job exploring this issue along the lines of what Tariq was alluding to. It was written more than 15 years ago but still absolutely applies. I think that's where you'll find out some surprising things about software engineering that ring true - at least to me as a (mostly) self-taught programmer, and about how science, engineering, and art intersect in the activity we call programming. If you're looking at this from the perspective of how this affects your workflow, there's also a great talk by Martin Fowler and Neil Ford of ThoughtWorks that further explores the effect Frederick Taylor's theories on scientific management have had on us. It's an Agile talk, but it's intertwined. There's also the pretty famous Mythical Man-Month by Frederick Brooks that explored this over 40 years ago. I'm sure there's much much more, but those are the most enlightening resources I think of off the top of my head.
It's a great question. Thanks for raising it!
Thanks for all the resources! 'Software Craftsmanship' seems most interesting - I don't think I've read an argument (yet) about how software engineering isn't enough. I've heard plenty about how it's overkill or not true engineering.
Yeah, software engineering is not true engineering as far as I understand it. Computers are still too young and so you can't create truly defined processes out of it. But that doesn't mean it's not valuable.
Read the book. It's under 200 pages so it's a quick read. It'll start to answer your question better than I can in the time I've got.
Hi Erika,
When you say "the term 'Software Engineer' is protected" in Canada, what exactly does that mean? Does it mean you have to have a certain education to be able to call yourself a Software Engineer, regardless of the job you do, or could someone "audit" the role to verify that it contains the responsibilities required to warrant the title?
I studied as a Computer Scientist (as in I studied Computer Science), but I work as a software engineer. Not everyone with the title have studied computer science. I'm sure in many other disciplines there are similarly undefined titles. For example, what does it mean exactly to be a "community manager" or a "legal advisor". Those roles probably vary just as much both when it comes to responsibilities and education and experience.
Unfortunately it seems that the title is somewhat thrown around which is confusing but in Canada, the title of "Engineer" is protected by law.
It's my understanding that it is illegal for someone to calls themselves an engineer (practising, licensed, or professional) with the intent to mislead a client into thinking that they will practice/execute regulated engineering work. To quote Engineers Canada, an "engineer is an individual who has been issued a license to practice engineering by a provincial ... engineering regulatory body after demonstrating they have the requisite skills, knowledge and experience." This means you have to had graduated from an accredited engineering program, and then registered with APEG for your province (e.g., APEGBC). Within APEG, you start as an "Engineer in Training (E.I.T.) while you work under a superior Professional Engineer (P.Eng) who assumes responsibility for your work. After 4 years, you can apply to be a P.Eng yourself, and therefore use the title "Professional Engineer." Further, APEG is self-regulating, meaning they are able to persecute/fine engineers (potentially revoking licenses) if they don't behave ethically.
That's interesting. I'd like to think that it's also illegal to "call oneself an engineer" .. "with the intent to mislead a client" in Denmark and most other places. But I don't think there is such a body in charge of determining who is worthy of the title.
It looks like the US added a professional engineer software engineer specification in 2013.
Thanks for the link! I'll have to look into that to see what the US position is now.
I think that someone who is considered Software Engineer must have solid knowledge of OOP, the importance of a clean code, know about software architecture, development practices, usability, software quality, and more, too should have some years of experience in different roles. The studies really are relative, many times the university does not prepare you for the work, the technology and the software advances quite fast so that the self learning is essential.
I also concur that an understanding in all the areas that make up software development are extremely important for one labeled a software engineer, this person should be more proactive in their approach. While the developer label, to me, belongs to one that creates software solutions and may have formal education they don't engineer the software and tend to be more reactive versus proactive. A programmer doesn't need any formal education just some experience or some internet skills.
I really like that thought, 'reactive' vs 'proactive.' Thanks!
Any path you choose for studying means you have a chance to learn all of these things but I like how you said a SE 'must have solid knowledge.' Seems to imply that this type is expected to have practical and theoretical know-how, not just one or the other.
Any discussion on Software Engineering should start with the 1968 NATO Software Engineering Conference in Garmisch, Germany and the 1969 follow-up conference in Rome, Italy. The reports on these two conferences are available online.
I think it is essential to read these reports for two reasons. First, these two conferences actually invented and popularized the term "software engineering". Second, the reports from these two conferences indicate major issues with software development as identified in the 1960s. We can use the benefit of hindsight to determine whether current software practices were effective in addressing those issues or if we still have work to do.
If I ever get time, I'll find some way to summarize the insights of these reports and provide my own commentary on them.
Great resource, thank you! I will look into these and give them a read. I'll keep an eye out for your commentary as well.
This is an extremely interesting subject. As a software development freelancer,I really struggle with "labeling" myself. Primarily because different organizations define their roles and expectations completely differently so trying to defining myself to suit their expectations is difficult.
Over the years I have operated in roles which have been defined as : Analyst Programmer, Programmer, Applications Developer, Senior Developer, Developer, Consultant Developer, Software Delivery Consultant, Software Engineer, Solution Engineer, Solution Architect, Software Architect, System Architect, System and Solution Architect, Back-end System Engineer, Lead Developer, Integration Engineer.
Although the title has changed, I have pretty much found myself pretty much doing the same job, i.e. writing software to solve particular business problem.
The make up of skills and qualifications on teams has also been completely varied. i.e. Zoologists, Geologists, MBA's, Economists, Electrical Engineers.
I really appreciate this answer - thank you! I get the feeling now that this labelling problem is common across disciplines. There's (thankfully) no pigeonhole where one would be restricted to work being a Software Engineer/Computer Scientist/Freelancer. At the end of the day, you're solving problems with software, and I suppose your primary problem defines your role. Consulting vs working data vs designing the system.
Definitely. I also think the problem is further exasperated when ti comes to defining Developer. Lately the moniker "Full Stack Software Developer" is banded about, without any real definition of what the terms means.
For instance, I label myself as a full stack software developer, because I am comfortable at any application tier .i.e UI, Middle and Database. I am by no means an in-depth expert at any of these tiers. e.g. I don't know the ins and outs of User Experience and UI design and graphic design, but I work with css, sass, html, javascript. I also don't know everything there is know about API design etc, but I have more than enough working knowledge to develop them using formal software development patterns and practices. I am also no expert in Database administration, but I can certainly design databases and write queries.
That being said, I am now witnessing that the term full stack development now requires knowledge of IoT, mobile , web and Business Analysis, Architecture etc.
This closely resembles what I would call software engineering, but job descriptions never stipulate Software Engineer, they ask for Full Stack Developer.
I do think in general our industry does have a hard time in being able to describe what we actually do on a day to day basis and in truth our roles are multi faceted.
Daily I find myself writing code, however I am also administrating Linux, MacOSX and Windows servers, networking, Databasee design etc
I think you hit the nail on the head. When it comes down to it I think all of them are buzzwords to fluff up a job but in the same sense it can be compared to something like college and university. A college is more hands on and can prepare you for a job while university teaches you theory and how it can be applied in other situations.
Are you referring to a technical college vs. bachelor degree program at a University? I totally agree with you there - that type of college is definitely more honed on learning direct skills (a polytechnic, for example) but depending on the program, a university might offer a blend of pure theory and pure skill depending on their accreditation.
Would you say that from a college graduate you expect more of a "get it done" mentality? Versus a university graduate who might be more broad in their knowledge and needs specific training?
Yes along those lines. I was using it as more of an example. A software engineer is someone who knows the theory rather than someone who just knows how to get it done.
To sum things up, one should have technical + theoretical knowhows of each and every aspect covered in one project life cycle. A software industry does seek a lot of these things in the end. To conclude, these Venn diagrams should in someway merge with each other. But then it depends on what track or path one individual would prefer to follow. One can just focus on theory and do research while the other can be more into developing things practically rather than thoeratically.
I have a Ph. D. on the subject and a lot of practical experience gained after I got my Ph. D. From that I can tell you the following:
Conversely it is true that a lot of the literature on software engineering (academic and non academic) is lacking in academic rigor and the industry is full of "evangelists" who peddle opinion as peer reviewed facts and seem to be perpetually confused about how unscientific some of the stuff they are peddling is in terms of empirical research that validates the effectiveness of what they are peddling. If you've ever tried to deal with some inexperienced developers trying to do scrum "by the book", you'll know what I mean (the book actually says: don't do that).
I know in Canada being an Engineer has special rules and requires a license granted by professional engineering associations but I feel like software development is an engineering job. I've studied electronics engineering and moved to software development and work as a software engineer, so I was partially thought like CS Studnet at the University, partially by myself and partially by training in the company so I believe I can compare those ;)
I think professional work will teach you the most out of the three (practice makes perfect), not only on software/web development itself but mostly about applying the solutions to real-world problems.
I think you can learn the principles by yourself, you can learn languages, clean code, design patterns, anything you need/want. I believe if you want to, you can actually learn more at home/by yourself than at the university sometimes (much depends on your University teachers and your attitude, really).
But the first clash with a real app is always challenging and applying your knowledge to the real system - that's the most valuable thing and that what the engineering is about (the application of mathematics and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations - per Wikipedia)
Ps.: I recently wrote my view on 'software engineer' and the definition on my blog jumpstart.blog/2017/05/22/id-rathe... if you're interested ;)
Just came across this article today which is very relevant to the discussion.
motherboard.vice.com/en_us/article...
I also have an Electrical Engineer degree, and am currently employed as a Software Engineer. While I don't have a P.E. for either I am certainly and Engineer and will call myself one.
I don't need a license to be an Engineer.
Thanks for following up and posting well over a month later! Much appreciated.
Article definitely generates some thoughts, and I certainly don't know enough about professional titles and engineering in the US to comment. Always interesting to compare the difference between countries.
You've raised a number of interesting questions that I'd hesitate to say have definitive answers.
Computer science and software engineering are vast, varied fields, so much so that a person specializing in cryptographic algorithms may be so different from a web UI designer that it would be highly misleading at best to say they do a single thing, called "software engineering".
That is to say, some "software engineers" are basically applied mathematicians; others are your garden-variety software developers; others are more like artists; still others are technically competent managers. The things they're expected to know can be as different from one another as vanilla ice cream and the Riemann hypothesis.
But you're getting at something else here:
That is absolutely true, but it has less to do with any "wild-west" quality to the tech field than with the fact that hiring good people is hard. If I wanted to know what you could do vis-a-vis a job I have, the only proven way of finding out is to plonk you in front of a machine and give you a job to do. That said, if I'm looking for someone to write web services in Java, or to work on machine-learning algorithms for identifying flowers on pictures of shirts, I have a pretty clear idea of what I'm looking for, and if I'm hiring I had better know the difference between a person competent at the one but not the other.
Many of the (very valuable!) resources already mentioned in the comments can help give you a good view of what many of us think of when we think about software engineering, what we might call "general-purpose software development". But what, exactly, we need to know to be effective in such jobs tends to differ from job to job and to change over time. So if I'm looking for a general-purpose developer, it's been my experience that being intelligent, open, and willing to learn goes much farther than the data structures class the candidate took in college.
it means nothing.
Interesting response. Care to elaborate? Is Software Engineering not needed in this day and age?
Relevant video (maybe):
DHH on 'writing software'
Thanks for the link!
for me, you can call yourself a software engineer when you know what you are doing or somewhat, and you truly understand the rules you are following
Which rules are you referring to?