5 ms·

>Since that conversation, I’ve come to the conclusion that there are three main pillars of being a good software engineer: writing code, debugging code and revi

>Since that conversation, I’ve come to the conclusion that there are three main pillars of being a good software engineer: writing code, debugging code and reviewing code. Not even close, my guy.

atleastoptimal 3y ago
ok what are they then?
- joeframbach 3y ago
  Laziness, impatience, and hubris.
  - atleastoptimal 3y ago
    Necessary but insufficient I'd argue the more important big 3 are obsession, organization, and ambition
    - chii 3y ago
      But those traits are hardly unique for software and coding greatness.
- Raidion 3y ago
  Not OP, but fwiw I think there are 2: Having the communications skills and domain knowledge to understand what problem needs to be solved and why, and having the technical skill to do that in the most direct manner that closely matches those constraints. Sometimes you need to get better technically, sometimes you need to get better at figuring out the problem (solving the wrong problem isn't worth a lot. regardless how "clean" it is). Sometimes you need to get better at figuring out what you need to get better at.
  - matthewfcarlson 3y ago
    I’d add the ability to communicate that problem to your first pillar. Code reviews are really just a forum to discuss and communicate the solution to a specific problem
- aprdm 3y ago
  shipping what business requires, and communicating with other humans
- dasil003 3y ago
  Understanding, communicating and ultimately convincing when it’s better not to write code.
- strken 3y ago
  As a software engineer, you should be doing some engineering. What that means is taking fuzzy human problems, expressing them as rigorously as needed, and solving them as cost-effectively as possible. Code is the means by which you express and solve a problem, not the whole process. Saying software engineering is about writing code is like saying civil engineering is about arranging girders in CAD: it's funny, has a grain of truth to it, is probably what your mum and dad think you do, but is a very surface-level understanding of what's going on. Where's the requirements-gathering? Where's the scoping? Where's the evaluation of different implementations? Where's the risk analysis? Where's the human planning for change management? Where's the part where you go and read a textbook on dimensionality reduction to try to understand the recommender system? The empirical understanding of the running system? Where are all the other things that go into building and running a software system that are the engineer's responsibility and aren't just code? EDIT: Not to say that getting good with your tools isn't a massive part of the job! It's just...the part of the job where you plan everything out is as important as the part where you pick up your tools and begin. When you start working as a software engineer, everything is about code because you need to know how to code as a foundation. All the other stuff comes later.
owenpalmer 3y ago
easy to deny a claim. difficult to prove it wrong.

>Since that conversation, I’ve come to the conclusion that there are three main pillars of being a good software engineer: writing code, debugging code and reviewing code. Not even close, my guy.

atleastoptimal 3y ago

ok what are they then?

joeframbach 3y ago
Laziness, impatience, and hubris.
- atleastoptimal 3y ago
  Necessary but insufficient I'd argue the more important big 3 are obsession, organization, and ambition
  - chii 3y ago
    But those traits are hardly unique for software and coding greatness.
Raidion 3y ago
Not OP, but fwiw I think there are 2: Having the communications skills and domain knowledge to understand what problem needs to be solved and why, and having the technical skill to do that in the most direct manner that closely matches those constraints. Sometimes you need to get better technically, sometimes you need to get better at figuring out the problem (solving the wrong problem isn't worth a lot. regardless how "clean" it is). Sometimes you need to get better at figuring out what you need to get better at.
- matthewfcarlson 3y ago
  I’d add the ability to communicate that problem to your first pillar. Code reviews are really just a forum to discuss and communicate the solution to a specific problem
aprdm 3y ago
shipping what business requires, and communicating with other humans
dasil003 3y ago
Understanding, communicating and ultimately convincing when it’s better not to write code.
strken 3y ago
As a software engineer, you should be doing some engineering. What that means is taking fuzzy human problems, expressing them as rigorously as needed, and solving them as cost-effectively as possible. Code is the means by which you express and solve a problem, not the whole process. Saying software engineering is about writing code is like saying civil engineering is about arranging girders in CAD: it's funny, has a grain of truth to it, is probably what your mum and dad think you do, but is a very surface-level understanding of what's going on. Where's the requirements-gathering? Where's the scoping? Where's the evaluation of different implementations? Where's the risk analysis? Where's the human planning for change management? Where's the part where you go and read a textbook on dimensionality reduction to try to understand the recommender system? The empirical understanding of the running system? Where are all the other things that go into building and running a software system that are the engineer's responsibility and aren't just code? EDIT: Not to say that getting good with your tools isn't a massive part of the job! It's just...the part of the job where you plan everything out is as important as the part where you pick up your tools and begin. When you start working as a software engineer, everything is about code because you need to know how to code as a foundation. All the other stuff comes later.

owenpalmer 3y ago

easy to deny a claim. difficult to prove it wrong.