Yeah agree 100%.

Unless you’re implementing a standard, software engineering is 50% communication with peers/clients/users, if not more..

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.

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.

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?

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.

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.

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?

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.

I'll rephrase my point:

  This dismissal of business requirements as not generating technical problems big enough to require deep work is very interesting.

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.

I think even the 'web app meeting business requirements' is equally deep work, and even more difficult than your kernel scheduler example since it involves working within often ill-defined business requirements.

Yes, absolutely depends on the work. I guess the farther you are from the front end of the interaction with an end user, the less you have to worry about a mountain of edge cases.

I would caution against saying there is no deep work required in web app implementation, every case is different, every person has a different threshold for what they consider "deep work". I can be knitting and consider it deep work.