7 ms·

> 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the mo

> 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the more you realise you were wrong. Having an opinion has often come to mean one is a fan boy of something and will have it no other way. I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all customer data together" Bad opinions formed can be dangerous and counter productive. Though I do agree that an opinion based on having a well thought out plan and experience is a sign of maturity.

jgilias 5y ago
I think that there is a very important distinction between having opinions, and willing to have it 'my way only'. I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.
jrimbault 5y ago
I think points 11 and 15 (Don’t mistake humility for ignorance) play of each other. I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.
moonchrome 5y ago
The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top. PHP and node come to mind immediately. Ruby is down right retarded with promoting Concerns for modeling cross cutting concerns and fat controller/model is a pattern for creating technical debt. Dealing with python environments and packages makes me want to avoid python if at all possible. Using C# and Java means I'm probably going to have 3 projects for a hello world. I'm not positively opinionated about my tools - it's more about deciding which one sucks least for a particular task.
- kortex 5y ago
  > Dealing with python environments and packages makes me want to avoid python if at all possible. I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow. Quick rundown: - don't use python2. Ever. - don't use the system python, or brew python for anything other than bootstrapping - only use `pip install --user` for exactly one thing: `pip install --user pipx` when you don't have brew - never, ever, ever `sudo pip` anything. No exceptions. - use pyenv to manage your python versions. - use `pipx` to install stand-alone CLI tools, like virtualenvmanager, poetry, black, mypy. - always develop in virtualenvs. No exceptions - prefer installable python packages over scripty standalone .py files - using PYTHONPATH is a smell - poetry is likely the future of tooling, but it's not mature enough to be considered best practice for python beginners just yet. Stick with pip if you are uncertain. - use lockfiles for writing applications but not writing libraries - editable installs are a double-edged sword
  - marcosdumay 5y ago
    None of that fix the fact that 3 years later, all of your dependencies will have conflicting requirements.
  - jfk13 5y ago
    I think the fact that you feel working with python requires adhering to a specific 12-step programme may go some way to explaining why I've never gotten comfortable with it.
    - hereforphone 5y ago
      I love Python and the Python 2-3 debacle really soured things for me as well. It was hard to get over that hump and I can understand that many were put off by it forever.
- heartbreak 5y ago
  Your comment about Ruby is actually referring to the Rails framework. It also suffers for the slur.
jtanderson 5y ago
While I agree, I think the essence of this comment is that the converse of OP is not true, i.e. "you should trust a senior engineer that has strong opinions". As a sibling pointed out, it's sort of two steps: 1) make sure they have opinions, then 2) ask yourself if those opinions are that of a fan-boy or somebody who has been around the block enough to know a thing or two.
scottious 5y ago
> I have heard team leads say "this python code is bad because it uses no classes" And they'll say it's "best practice". "best practice" has basically come to mean "whatever that particular developer knows/likes"
- bussierem 5y ago
  Just to be fair: in Python, there are "best practices". They're in PEP-8. If someone is making a claim about anything outside PEP-8 (like whether to use classes) or worse, AGAINST PEP-8...that's when you know there's a problem.
MaxBarraclough 5y ago
Right, there's a big difference between an engineer with well-founded opinions, and a fanboy with strong emotions. If you can't explain the weaknesses of your favourite tools, that's not a good sign. If you can't explain your preference for one tool over another, that's a bad sign. It's disappointing to encounter developers who, for example, love C# but hate Java, and are entirely unable to articulate why. They're very similar languages! Somewhat related: Rich Hickey (of Clojure fame) makes the point that one of the disappointing aspects of the software development community is that there's so much talk about 'better', and so little about trade-offs.

jgilias 5y ago

I think that there is a very important distinction between having opinions, and willing to have it 'my way only'. I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.

jrimbault 5y ago

I think points 11 and 15 (Don’t mistake humility for ignorance) play of each other. I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.

moonchrome 5y ago

The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top. PHP and node come to mind immediately. Ruby is down right retarded with promoting Concerns for modeling cross cutting concerns and fat controller/model is a pattern for creating technical debt. Dealing with python environments and packages makes me want to avoid python if at all possible. Using C# and Java means I'm probably going to have 3 projects for a hello world. I'm not positively opinionated about my tools - it's more about deciding which one sucks least for a particular task.

kortex 5y ago
> Dealing with python environments and packages makes me want to avoid python if at all possible. I see this a lot, and I don't blame folks for having this stance. It's taken me over a decade to dial in my workflow. Quick rundown: - don't use python2. Ever. - don't use the system python, or brew python for anything other than bootstrapping - only use `pip install --user` for exactly one thing: `pip install --user pipx` when you don't have brew - never, ever, ever `sudo pip` anything. No exceptions. - use pyenv to manage your python versions. - use `pipx` to install stand-alone CLI tools, like virtualenvmanager, poetry, black, mypy. - always develop in virtualenvs. No exceptions - prefer installable python packages over scripty standalone .py files - using PYTHONPATH is a smell - poetry is likely the future of tooling, but it's not mature enough to be considered best practice for python beginners just yet. Stick with pip if you are uncertain. - use lockfiles for writing applications but not writing libraries - editable installs are a double-edged sword
- marcosdumay 5y ago
  None of that fix the fact that 3 years later, all of your dependencies will have conflicting requirements.
- jfk13 5y ago
  I think the fact that you feel working with python requires adhering to a specific 12-step programme may go some way to explaining why I've never gotten comfortable with it.
  - hereforphone 5y ago
    I love Python and the Python 2-3 debacle really soured things for me as well. It was hard to get over that hump and I can understand that many were put off by it forever.
heartbreak 5y ago
Your comment about Ruby is actually referring to the Rails framework. It also suffers for the slur.

jtanderson 5y ago

While I agree, I think the essence of this comment is that the converse of OP is not true, i.e. "you should trust a senior engineer that has strong opinions". As a sibling pointed out, it's sort of two steps: 1) make sure they have opinions, then 2) ask yourself if those opinions are that of a fan-boy or somebody who has been around the block enough to know a thing or two.

scottious 5y ago

> I have heard team leads say "this python code is bad because it uses no classes" And they'll say it's "best practice". "best practice" has basically come to mean "whatever that particular developer knows/likes"

bussierem 5y ago
Just to be fair: in Python, there are "best practices". They're in PEP-8. If someone is making a claim about anything outside PEP-8 (like whether to use classes) or worse, AGAINST PEP-8...that's when you know there's a problem.

MaxBarraclough 5y ago

Right, there's a big difference between an engineer with well-founded opinions, and a fanboy with strong emotions. If you can't explain the weaknesses of your favourite tools, that's not a good sign. If you can't explain your preference for one tool over another, that's a bad sign. It's disappointing to encounter developers who, for example, love C# but hate Java, and are entirely unable to articulate why. They're very similar languages! Somewhat related: Rich Hickey (of Clojure fame) makes the point that one of the disappointing aspects of the software development community is that there's so much talk about 'better', and so little about trade-offs.