5 ms·

Your level as an engineer should be based on how much deep work you can do without screwing the pooch. The best engineers can be left alone for months and be s

Your level as an engineer should be based on how much deep work you can do without screwing the pooch. The best engineers can be left alone for months and be sure to return with something cogent. The most junior will be required to have daily design check ins and regular code reviews as they go from start to finish on a project whose problem space needs to be well understood and mapped out before any deep work begins. It is very damaging to an organisation when someone who cannot create understandable solutions is given the deep work breathing space to go crazy. It is a difficult but important thing to find out about candidates / probationary employees sooner rather than later. It’s important to keep a stash of pre-baked project ideas on hand so that you can use them to assess newcomers to the team, especially if you only have three months to figure out if they are able to meet your expectations before being confirmed as a full time employee.

mym1990 4y ago
An engineer being left alone for months just sounds like a great way for a user to ask for one thing and get something completely different. I think most engineers would love to just be left alone for days or even hours at a time, and that sounds a lot more reasonable.
- kamilafsar 4y ago
  Yeah agree 100%. Unless you’re implementing a standard, software engineering is 50% communication with peers/clients/users, if not more..
- atoav 4y ago
  My best code I have written ever was written like this. I got a very good introduction of the problem, the imagined solution(s) and how the problem is currently solved by different people and what they like/dislike. After that I proposed some rough direction, they said yes and of I went. Arguably I sent some updates in between, but all was unsychronous. No meetings, no presentations. Just me doing the thing. How well you can focus on solving the actual problems when you are actually in charge of your time.
- woolion 4y ago
  He means alone for "code supervision". That means you communicate with clients and/or analysts for your specs, but don't get code review or anything else from a senior engineer. No advice on how to architect, when to refactor, etc.
  - mym1990 4y ago
    But if you're working on something so complex that it needs 6 months of heads down time...and you're not getting any technical feedback or advice...is that not a huge red flag?
    - yencabulator 4y ago
      Grandparent said > Your level as an engineer should be based on how much deep work you can do without screwing the pooch. A really good engineer can do 6 months of head-down work without a disaster. A really good engineer does not need technical feedback or advice in that time, as long as the problem is clear enough in the beginning. Here, try this as a though exercise: "Create a new distributed nosql database that uses WASM modules for non-interactive transactions." A really good engineer really, really, doesn't need "technical feedback" during the process to implement that.
- badpun 4y ago
  Depends on the work. If it's your typical web app implementing some business requirements, then there's no deep work required - it's just talking to the requirements source and converting that into code, as per the chosen web framework. On the other hand, if the work is technical (say, you're working on a new kernel scheduler or a new voxel engine), then being left alone for weeks or months is perfectly reasonable. For example (from what I've read), that's how kernel engineers at Microsoft are expected to work.
  - pdhborges 4y ago
    This dismissal of business requirements as not technical is very interesting. Don't you ever get business requirements that touch hundreds of existing use cases? Or business requirements that sudenly require paying atention to concurrency in multiple parts of the code? Or business requirements that introduce processes that produce and process huge amounts of data?
    - plaguepilled 4y ago
      Business requirements are absolutely crucial, but they are not in any way technical. Conflating business and technical requirements just means the business requirements are not understood correctly.
      - pdhborges 4y ago
        I'll rephrase my point: This dismissal of business requirements as not generating technical problems big enough to require deep work is very interesting.
        TeMPOraL 4y ago
        I think you need to look at the whole sentence: > If it's your typical web app implementing some business requirements, then there's no deep work required - it's just talking to the requirements source and converting that into code, as per the chosen web framework. The key phrase is typical web app. The sentence isn't saying that business requirements always generate shallow work. They're saying that working on a typical web app is almost entirely shallow work.
ResearchCode 4y ago
Daily "check ins" is way excessive. One status meeting a week is plenty. If they're also should-you-be-fired-today interrogations, then it appears that the organizations real problem is toxicity.
- wildrhythms 4y ago
  I frequently find the people demanding daily check-ins at my workplace are the ones lacking direction, and can't 'deeply' engage with the work for that reason, usually because their managers also lack direction (poorly defined vision, poorly defined requirements, etc) I wish managers could realize that 'more collaboration' by way of frequent meetings doesn't equal more productivity for the people who are actually doing the work.
- ZephyrBlu 4y ago
  For someone inexperienced it's really not. They don't have the intuition to know when it's time to cut your losses and move on from a dead end, and they don't know when to ask someone else for input. A full week without supervision on an open ended problem is likely to get them extremely tangled up in a bad solution.
- deterministic 4y ago
  One status email per week is plenty. I have worked like that for years and been super productive.
danuker 4y ago
> The best engineers can be left alone for months and be sure to return with something cogent. As a customer, this would be absurd. If I don't get what I imagined I wanted (rather than what I said), I'd rather find out in time to ask you to steer the solution towards what I want, instead of you bankrupting me for a wrong solution. Frequent feedback is the essence of Agile. It makes sure the development process addresses the business needs with lowest latency and lowest gap in understanding. https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
- eastAligned 4y ago
  Sometimes you find a problem or a region for improvement that can be clearly defined and self contained, then given to an engineer or small team to work on until it's done. Some areas have more of these potential problems than others; in robotics adjacent companies they are more frequent than finance (in my experience). Not everything is best managed by agile.
  - tonyarkles 4y ago
    > in robotics adjacent companies they are more frequent than finance (in my experience). I’m laughing a bit because I’ve been reading through this thread thinking about what I’ve been working on for the last few months. Robotics-adjacent, lots of calculus, differential equations, linear algebra, ray tracing, optics, yadda yadda. I’ve worked on more businessey problems a ton in the past. I built a company that made bespoke LOB applications. This work is way different. Agile was great for that. I would absolutely love to be left alone for a few weeks to just finish getting through all of this analysis. Going a couple of weeks in LOB-app land without feedback would be a train wreck the vast majority of the time.
- eikenberry 4y ago
  IMO if you are working on a problem that needs stakeholder feedback then it is not the sort of deep problem the OP is talking about. Deep work is usually not Agile in nature. It is about diving into a hard problem, not iterating on standard features/bugs.

mym1990 4y ago

An engineer being left alone for months just sounds like a great way for a user to ask for one thing and get something completely different. I think most engineers would love to just be left alone for days or even hours at a time, and that sounds a lot more reasonable.

kamilafsar 4y ago
Yeah agree 100%. Unless you’re implementing a standard, software engineering is 50% communication with peers/clients/users, if not more..
atoav 4y ago
My best code I have written ever was written like this. I got a very good introduction of the problem, the imagined solution(s) and how the problem is currently solved by different people and what they like/dislike. After that I proposed some rough direction, they said yes and of I went. Arguably I sent some updates in between, but all was unsychronous. No meetings, no presentations. Just me doing the thing. How well you can focus on solving the actual problems when you are actually in charge of your time.
woolion 4y ago
He means alone for "code supervision". That means you communicate with clients and/or analysts for your specs, but don't get code review or anything else from a senior engineer. No advice on how to architect, when to refactor, etc.
- mym1990 4y ago
  But if you're working on something so complex that it needs 6 months of heads down time...and you're not getting any technical feedback or advice...is that not a huge red flag?
  - yencabulator 4y ago
    Grandparent said > Your level as an engineer should be based on how much deep work you can do without screwing the pooch. A really good engineer can do 6 months of head-down work without a disaster. A really good engineer does not need technical feedback or advice in that time, as long as the problem is clear enough in the beginning. Here, try this as a though exercise: "Create a new distributed nosql database that uses WASM modules for non-interactive transactions." A really good engineer really, really, doesn't need "technical feedback" during the process to implement that.
badpun 4y ago
Depends on the work. If it's your typical web app implementing some business requirements, then there's no deep work required - it's just talking to the requirements source and converting that into code, as per the chosen web framework. On the other hand, if the work is technical (say, you're working on a new kernel scheduler or a new voxel engine), then being left alone for weeks or months is perfectly reasonable. For example (from what I've read), that's how kernel engineers at Microsoft are expected to work.
- pdhborges 4y ago
  This dismissal of business requirements as not technical is very interesting. Don't you ever get business requirements that touch hundreds of existing use cases? Or business requirements that sudenly require paying atention to concurrency in multiple parts of the code? Or business requirements that introduce processes that produce and process huge amounts of data?
  - plaguepilled 4y ago
    Business requirements are absolutely crucial, but they are not in any way technical. Conflating business and technical requirements just means the business requirements are not understood correctly.
    - pdhborges 4y ago
      I'll rephrase my point: This dismissal of business requirements as not generating technical problems big enough to require deep work is very interesting.
      - TeMPOraL 4y ago
        I think you need to look at the whole sentence: > If it's your typical web app implementing some business requirements, then there's no deep work required - it's just talking to the requirements source and converting that into code, as per the chosen web framework. The key phrase is typical web app. The sentence isn't saying that business requirements always generate shallow work. They're saying that working on a typical web app is almost entirely shallow work.

ResearchCode 4y ago

Daily "check ins" is way excessive. One status meeting a week is plenty. If they're also should-you-be-fired-today interrogations, then it appears that the organizations real problem is toxicity.

wildrhythms 4y ago
I frequently find the people demanding daily check-ins at my workplace are the ones lacking direction, and can't 'deeply' engage with the work for that reason, usually because their managers also lack direction (poorly defined vision, poorly defined requirements, etc) I wish managers could realize that 'more collaboration' by way of frequent meetings doesn't equal more productivity for the people who are actually doing the work.
ZephyrBlu 4y ago
For someone inexperienced it's really not. They don't have the intuition to know when it's time to cut your losses and move on from a dead end, and they don't know when to ask someone else for input. A full week without supervision on an open ended problem is likely to get them extremely tangled up in a bad solution.
deterministic 4y ago
One status email per week is plenty. I have worked like that for years and been super productive.

danuker 4y ago

> The best engineers can be left alone for months and be sure to return with something cogent. As a customer, this would be absurd. If I don't get what I imagined I wanted (rather than what I said), I'd rather find out in time to ask you to steer the solution towards what I want, instead of you bankrupting me for a wrong solution. Frequent feedback is the essence of Agile. It makes sure the development process addresses the business needs with lowest latency and lowest gap in understanding. https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html

eastAligned 4y ago
Sometimes you find a problem or a region for improvement that can be clearly defined and self contained, then given to an engineer or small team to work on until it's done. Some areas have more of these potential problems than others; in robotics adjacent companies they are more frequent than finance (in my experience). Not everything is best managed by agile.
- tonyarkles 4y ago
  > in robotics adjacent companies they are more frequent than finance (in my experience). I’m laughing a bit because I’ve been reading through this thread thinking about what I’ve been working on for the last few months. Robotics-adjacent, lots of calculus, differential equations, linear algebra, ray tracing, optics, yadda yadda. I’ve worked on more businessey problems a ton in the past. I built a company that made bespoke LOB applications. This work is way different. Agile was great for that. I would absolutely love to be left alone for a few weeks to just finish getting through all of this analysis. Going a couple of weeks in LOB-app land without feedback would be a train wreck the vast majority of the time.
eikenberry 4y ago
IMO if you are working on a problem that needs stakeholder feedback then it is not the sort of deep problem the OP is talking about. Deep work is usually not Agile in nature. It is about diving into a hard problem, not iterating on standard features/bugs.