6 ms·

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

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.

mewpmewp2 4y ago
If you keep your opinions to yourself, there's no one to challenge them and so your opinions won't improve.
- sibit 4y ago
  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.
taco_emoji 4y ago
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.
rawgabbit 4y ago
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.
kqr 4y ago
> 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.
- m_mueller 4y ago
  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).
  - kqr 4y ago
    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?
hulahoof 4y ago
Strong opinions weakly held has worked well for me
- gwd 4y ago
  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.
  - johnnny 4y ago
    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.
    - soiler 4y ago
kstenerud 4y ago
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.
koonsolo 4y ago
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.
- mewpmewp2 4y ago
  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.
- kqr 4y ago
  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!)
  - sumtechguy 4y ago
    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.
underdeserver 4y ago
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.
NumberCruncher 4y ago
>> The former knows enough about the state of the art in their area of the field Considering something to be "state of the art" is highly subjective, therefore nothing else than an opinion.
- agentultra 4y ago
  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.

mewpmewp2 4y ago

If you keep your opinions to yourself, there's no one to challenge them and so your opinions won't improve.

sibit 4y ago
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.

taco_emoji 4y ago

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.

rawgabbit 4y ago

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.

kqr 4y ago

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

m_mueller 4y ago
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).
- kqr 4y ago
  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?

hulahoof 4y ago

Strong opinions weakly held has worked well for me

gwd 4y ago
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.
- johnnny 4y ago
  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.
  - soiler 4y ago

kstenerud 4y ago

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.

koonsolo 4y ago

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.

mewpmewp2 4y ago
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.
kqr 4y ago
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!)
- sumtechguy 4y ago
  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.

underdeserver 4y ago

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.

NumberCruncher 4y ago

>> The former knows enough about the state of the art in their area of the field Considering something to be "state of the art" is highly subjective, therefore nothing else than an opinion.

agentultra 4y ago
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.