Nice post! As a software dev of more than twenty years myself I nodded along with most of this list.
I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth.
Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them.
For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.
> For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
The junior/senior distinction is so coarse-grained. Expert research sometimes uses nomenclature inspired by guild terminology, e.g.
- an initiate has just started learning the subject;
- an apprentice has basic knowledge but still needs guidance from someone more experienced to go through their day;
- a journeyman is skilled and reliable and can go through a day's work unsupervised but still need direction from someone more experienced, many people are journeymen for life;
- an expert is a top-level journeyman who is looked at as someone who can deal with unusually tough problems;
- a master is a leader in the field, someone who can train experts.
It's not perfect, but it's a strict improvement over what we are doing now.
I especially like the operational definition of when one goes from an apprentice to a journeyman. It's a fairly obvious distinction: can you do a day's work unsupervised? Much easier to determine than when one goes from junior to senior.
I'm coming from a culture where this scheme is still applied to various crafts. I agree very much and think it would fit quite well for software engineer, though I think starting at the expert level there is an element of research / scientific thinking needed that academia tends to produce better results for.
The ideal career path would thus IMO involve some way to combine this vocational proficiency with a research stint, be it in academia or in industrial R&D. Switzerland is I think rather unique in allowing this combination, but by far most people (me included) still go through either one or the other (vocational vs. academic route).
Germany? I work with Germans and I always worry that their apprenticeships mean something different to what I have in mind. Do you have a link or something explaining how those skill levels are interpreted in your culture?
Switzerland in my case. It's quite similar, but with some extended vocational university options compared to Germany ('Fachhochschule'). Anyways, the way it generally works for most professions (and ~75-80% of population actually go through this route, rather than going straight to academia) is as follows:
* start apprenticeship at 16 for 3-4 years; 3-4 days per week of being embedded in a company as apprentice, 1-2 days of staying in school
* at the end of apprenticeship you do a test, both theoretical and practical. your 'apprentice master' (Lehrmeister) is judging your practical skills in form of an apprentice project. Passing that you're the equivalent of journeyman.
* you can now either start working full time, or you go back to school for 1y to get the federal professional maturity test ('Berufsmatura'). This allows you to enter any higher vocational school in your field in the country.
* from here you go on to either do a vocational university, or you could even take another test and go full on academia (say to ETH Zurich, University, whatever). That gives you the equivalent of BSc or MSc, depending on where you go and how long you stay.
* On top of the bologna titles, there is also the 'federally certified' titles. Say you wanna be a certified construction manager, you go do a federal certificate and become one of ~2500 people in the country with that title. It's highly sought after and a sign of quality. Think of it like professional master titles given by the French state, if you reach that you should never have to worry finding a job. You'll generally be >30y old at that point.
Now I'm curious so I'll pick your brain a bit. What happens if you want to change careers later in life? Do you go back to apprenticeships with other 16-year olds, or is there a different path for adult education?
And when you start a BSc at the earliest, you are something like 20 years old? (16 when you apprentice, 19 when you finish that, one more year plus two tests to enter university?)
I‘ve never seen adult apprentices, don’t think it exists. Rather you‘d do internships and evening schools, as everywhere else. The difference mainly comes from apprenticeships being the norm for teenagers, it creates IMO an environment of comparatively high skill levels in all kinds of trades. Maybe not too surprising that Germany and Switzerland are generally good at machines and fine mechanics.
20ish sounds about right - in Switzerland, men loose a year due to military/civil service.
We had someone doing an internship in our SWE company (Switzerland) whom I estimated about 60 years. But never heard of someone doing an apprenticeship beyond late twenties or so (may exist, though).
To be honest, I find the idea of classifying people from journeyman to master rather unsuitable for today's knowledge work. It does not pass the smell-test for gate-keeping.
What you need to know changes every five years. Call someone grand-master of software engineering, sure, but no matter how great they are they'll not get your CRUD database UI done any faster - if their career was all about signal processing for particle accelerators and medical device certification. More likely, they'll over-engineer and over-spec and not be prepared for requirements to change completely after a year, or for sinking several days into CSS layout issues. Beyond a certain baseline of experience (say, working five years in the field or so), what counts is knowing the domain well (interpreting what the customer wants). Or already having experience with the technology that applies to problem-of-the-day. Or being highly motivated to learn it.
It's not like crafting with wood. The nature of wood doesn't change every six months. The tools we use to work wood don't change every six months.
I like the craftsman analogy, and have used it myself. Maybe to attain "master" certification, software developers should be required to create a "masterpiece" the same way as craftsmen of old (this being the origin of the word - a piece of work that demonstrated your master-level skills).
Perhaps a compiler or something of similar complexity would be appropriate as a software "masterpiece". What else, I wonder?
I'm not sure what you're referring to as "BEAM". Google throws up a bunch of different software related things.
An operating system such as UNIX would for sure count as a "masterpiece", but I think that's really too big of a project. Should really be something that a single "master developer" could complete in a few months, or less than a year at least.
I also have 20 years of experience, and was thinking the same thing about the article. Liked everything except the opinions. But for me the reason is a bit different.
Everything has benefits and drawbacks, and you always know the drawbacks of something you use better. Decisions are always about tradeoffs, never about "strong opinions". For example we recently had a discussion about git normal merge vs squash. My opinion was "I lean towards normal merge, but maybe in our context we prefer squash. Let's check with the team members...". Now if you have a strong opinion on either one, I know you are inexperienced, because you cannot just throw away the benefits and drawbacks of either one. You might fool juniors who equal strong opinion with knowledge, but not me.
And on juniors vs seniors, the biggest difference I see is that juniors can really get stuck on a problem, with nowhere else to go. A senior is always able to find a way.
Ironically, you have a very strong opinion on people with strong opinions. Going as far as saying if you have a strong opinion on how to use git means you're a junior is a bit extreme, in my opinion.
I’m sure you could change his mind with a good reason. What reasoned argument can you give as to why it would be better to have a strong opinion about why one type of merge is always better.
Maybe you’ve seen the long term affects of squashing commits in several different contexts, and it always leads to a poor outcome eventually. Sure there might still be reasons to do it, but you’ve never seen a case where it’s worth the cost in the long term. Eventually with experience (and several different contexts), you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
Maybe this doesn’t actually apply to git merges, but I imagine that there are certain things that eventually emerge as having extraordinarily unfavorable trade-off ratios.
It’s hard for me to think of anything off the top of my head, but one example could be using global scope for all of your variables. Sure, it’s a small app now, but do you really want to rewrite everything later when it’s impossible to understand? Of course there are (tiny) benefits to building an app with all global variables, but it’s hard to imagine that is ever a worthwhile trade-off, and I think it’s fair to build a strong opinion that you should use (at least some) local scope.
> you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
I think a "measured" approach here would be to say that the evidence required to convince you that this would be a good idea raises which each new domain in which you see it fail. It's not to say that you cannot be convinced; but it's to say that the burden of proof is heavy.
I think it often is the "multiplication" of severity and frequency. Once burned badly enough gives a lot of weight to your preference, even though it is not what you typically associate with the word "measure".
It seems like you do have a strong opinion on git merge vs. squash. You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them. (You even go as far as saying that the latter is a signal of inexperience!)
For me I have found different paradigms to be useful. But sometimes just getting the team to agree on one system and one set of build tools can be an uphill battle. So sometimes you end up with 2 or 3 systems instead of one. For some things that is perfectly fine. But others it becomes a roadblock on bringing in new people. When starting a new job sometimes just where the bathroom is can be a bit of a chore much less trying to figure out what someone 3 years ago was arguing about and you just want to check some code in and get it reviewed. But when you first show up you probably at least want to get a lay of the land and figure out where the Chesterton's fences are before trying to 'fix it'. It could be they already had this discussion a few times. It could be they never considered it. But until you do it their way for a bit you will not be able to speak with any authority.
>You seem fairly convinced that one should adapt to local conditions and not doggedly stick to one of them
If there ever was an universal truth about any subject that's being dealt with by someone who knows even a little about said subject, it would be phrased approximately like that
"Don't be a zealot about $thing" shouldn't be considered a strong opinion
I remain a zealot about the harms of leaded gasoline and corruption, for example. Also the roundness of Earth, and the applicability of Newtonian physics at human scales. There are a large class of things you should be zealous about if someone offers opinion to the contrary!
Well that's such a topic that it's not really worth to have strong opinion over yes, but there are other things that will determine the success of an application or system, like whether you use REST, GraphQL, micro-services etc, so the architecture of those things, having knowledge to form an opinion about those would seem important. These type of things can matter in the future where they could have 10x productivity difference depending on the path you choose.
I've had great success with opinions. I'll solicit opinions and give my own. Opinions are a kind of chaos monkey for checking your assumptions and bringing aspects that you hadn't thought of into the discussion.
And since they're all coming from various sources of experience, they're going to be useful.
The trick is to not treat opinions as correct/false, but rather as components that help push your solution towards the limit of correctness. It's incredibly rare that a single opinion solves all.
The way I read the post is, the particular opinions that a senior engineer has are not very important or valuable.
It's that having strong opinions about your tools means you've used them a lot and have an emotional connection to them - be it positive or negative. Which is a proxy to caring about your craft.
The issue I have with this principle is how the strong opinions are presented. It's often not easy to tell the difference between "an inexperienced, non-authoritative, strong opinion weakly held" and "an experienced, authoritative, strong opinion strongly held".
If it's obvious that you're a junior dev -- that you have both little experience and little influence -- then expressing a strong opinion isn't really problematic, because other people will feel comfortable challenging it.
The problem comes as you start to gain experience and influence. As it becomes clear that you do have experience in general, then people are likely to assume that all of your strongly stated opinions are the result of experience, even when they're not. Thus people with a little bit of experience in X, hearing your strong opinion on X (even though you have zero experience) are more likely to discount their experience, rather than sharing their experience with you.
Similarly, people who are coming from the outside -- say, people from other companies talking to a team lead of a project; or contributors submitting to an open source project -- are more likely to hear opinion X as being, "This is the rule for this project", rather than "This is my current opinion, but feel free to challenge me if you think it's wrong".
So if you're going to hold strong opinions, you need to make it clear when you express them that they are in fact weakly held; and the more you grow as a developer, the more important it is.
I have heard of an anecdote that in some company, can't remember which, when meeting to take a decision, they would have people speak up in order of seniority, from the most junior to the most senior in the room. That way they could avoid the problem you're describing: you don't risk contradicting someone preceived as more experienced, or worse, your boss.
I found that an elegant solution, at least in abstract, I've never actually see it in practical use.
I can see how this sounds good, but my first reaction is that I think it is the kind of thing that would work great in a really good team that wouldn't even need it, and it would be awful for juniors in the kind of team that would get really excited about implementing it. Who wants to speak up when you don't know the ropes, you haven't gotten used to the social dynamic, etc? Seems to select for people with excessive confidence, who already have no difficulty advancing themselves.
This model seems insufficient and exclusionist to people who are socially withdrawn, or have a social disability, or come from a marginalized background, or any of the myriad reasons some developers already don't speak up. But it's a good starting point. I just would not implement it without additional frameworking to guide and encourage useful input from the juniors. In which case, if you're putting in the effort to understand why people aren't speaking more freely, this framework may be superfluous (or it could still be a valuable part of your practices).
That’s generally a good approach: it gets the thought out there, and others can take it under consideration, but without causing an ego wall to be erected.
If the subject is too important, you can “kindly emphasize”, but after that you’ve done your duty, and when the shit hits the fan, you’re covered.
It's not... you can feel really good or bad about something, but also be completely open to having your opinion shaped by new information and be willing to switch. That's what it means. As opposed to strongly holding opinions (whether they are strong or weak) and actively resisting conversion attempts.
The opinion itself is strong because it's absolute. It will be weakly held if, when presented a case where gotos really are a better solution, you give it up and decide to modify it to, "Never use gotos, except in a handful of well-defined cases, such as X."
Thanks. I think I am already following that policy. "Strong Opinions Weakly held". But generally, people see your strong opinions and automatically think you are difficult to work with or make some assumptions about you. They do not care about the "weakly held" part. Atleast, that is what I believe. But it works personally very well.
I interpreted the author's stance on opinions differently. I believe he meant that having a strong opinion on tools and architecture is a signal. A signal that the developer is battle tested, been there and done that, and have the scars to show for it.
When I read the bit about having strong opinions, my personal reaction is to recall when my team(s) wanted to ditch SQL Server for first MongoDB and then later CosmosDB. I physically felt sick.
IMO it has a lot to do with the how well the person is able to pick their battles.
Like, IMO it's weird if you DON'T have a strong opinion about tabs vs spaces. But if you're getting into serious, protracted arguments about this, then you lack the wisdom to prioritize the decisions that really matter.
I somewhat disagree. I think you can challenge yourself.
I'm typically the type of person who keeps my opinions to myself unless asked and when I disagree with someone about how to do/build something I'll do it myself on my own time. Sometimes I'm right and sometimes I'm wrong. As much as it sucks to realize I'm wrong I do appreciate it because it means I learned something and my opinion has improved.
The state of the art is not subjective in the sense that each individual defines their own (although in much of the software industry it can certainly seem that way). Take the SWEBOK [0] as an example. It is a collection of many individuals’ contributions to the body of knowledge; not just some conference speakers’ opinions.
Not everyone maintains or collects together all of the practices in their domain; software moves fast, so sometimes we have to rely on individuals’ experience and wisdom to know all of the different approaches, for example, to software testing in their domain and which ones are best suited to the project at hand.
Their opinion isn’t terribly useful if it goes against the requirements and specifications.
I disagree about the value of opinions. They’re generally bad, often wrong, and don’t solve anything. Have them, sure, but keep them to yourself unless asked. We like to think our opinions are reasonable, well researched, and unbiased but nothing is further from the truth.
Be open to changing your mind, let evidence and results guide you, always be open to learning new things! Opinions change with what you know so don’t hold on to them.
For me the biggest difference between a senior engineer and a junior engineer is experience. The former knows enough about the state of the art in their area of the field that they can train other people in what they know. Those people that they train go on to become senior engineers themselves.
One thing I’d add: if you’re a software developer, think about your principles. What maxims and rules guide your thinking? What do you value? I encourage writing those down and re-writing it every few years to see what has changed. Maybe one day you’ll be writing a list like this.