What I'm Up to Now

I remember it well, starting 2016 suddenly everyone wants to do DDD, CQRS etc. Let's shoehorn new paradigms in our framework of choice. Boilerplate, lots of boilerplate...

> that's how Fowler recommends it, so that's how we're doing it

Fowler would be the first to point out that there are no hard & fast rules / recommendations and each case should be evaluated individually since there's just too many variables.

Some never do though...

The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.

But, we probably don't build the same kinds of software. Shooting him down because he isn't talking about the kind of software you build is pretty ignorant.

https://martinfowler.com/bliki/MonolithFirst.html

Fowler shares ideas of architecture, but in a nuanced way, and clearly states when it might be appropriate, and what are the costs and complexities involved.

The problem in your case seems to be more of "Architecture Astronauts".

https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

I wouldn't be surprised if the mere existence of a software architect title incentivizes overly complicated architectures

https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

But, then, this just proves the business aphorism that, for your career, it is better to be part of a gigantic disaster than a modest success.

If you want to actually learn what they call "clean coding" (aka proper design, these guys are great at creating buzzwords, and great public speakers), the way to go is "Systematic Program Design" (in youtube [1], same material as edx's How To Code), which is based on the Htdp book ("how to design programs"), followed by MIT's OCW 6.005 [2] ("Software Construction").

Both are free. But who knows this? There is no one to hype them, no "movement" behind what are tried and trusted techniques, no flashy CQRS SOLID acronyms.

These two courses, instead, teach you timeless concepts and techniques that will survive all fads.

[1] https://youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w

[2] https://ocw.mit.edu/courses/electrical-engineering-and-compu...

Want to see the current state of a trade? Open and deserialize 50 objects and then manually make these classes pick the merging of all those fields.

Not like there are multiple database products out there with temporal support. Let's reinvent the wheel, baby!

Could you elaborate on this?

To me, HATEOAS always seemed like it wants me to basically re-invent the web browser. You know, the fact that basically no one does things this way may give you a hint on how actually useful it is.

This is also touching on burnout. There's just a kind of programming work that is mentally draining and unfulfilling because the underlying problems or mistakes are entirely self-inflicted. Spending time fixing shit that didn't have to be broken.

For me personally, this feeling arises when I become overly focused on an end-state. My mitigation is focusing more on the process and trusting that, over time, the end-goal becomes a natural outcome of an effective process.

I just accidentally raised $1,931 yesterday for Tensorfork Labs, a non-profit I started ... also yesterday. https://twitter.com/theshawwn/status/1431462744906141696

I was blown away that everyone suddenly offered so much support. We have people filling out notion docs (http://wiki.tensorfork.com/) and an active Google Chat chatroom with 12 interesting people in it. And to top it all off, Nat Friedman (Github CEO) DM'ed me last night and I'll be talking to him in approximately three hours.

You'd think I'd feel thrilled and like I'm extremely effective. I am thrilled, but all I feel is that I haven't done as much as I could. Talking and walking are two different things, and now that we've talked, it's time to walk the walk. But the truth is, I felt guilty sleeping most of today while everyone else has been talking excitedly. I felt that if I pushed myself a little harder, I could've been more effective, or more diligent, or lived up to my responsibilities more.

But that path leads to burnout. Good work is a marathon, and things take time. (Unfortunately it sometimes seems ~impossible to internalize that, and the temptation to sprint is always there.)

If you're looking for a mental hack to make the feeling go away, the only thing that helps me is to remind myself that even small deltas have value. My personal goal is to make imagenet2012 accessible to every programmer. It's a small, obscure itch that I am scratching for myself. But it's mine, and I can fix it, which is good enough.

So just do what you can, where you can, and be authentic. No one can know how things will play out. Doing your best is all you can ask of yourself.

He was perhaps smarter than me and worked harder. I asked him what it was that motivated him, and he said that it was a sense of guilt that had been instilled in him by his parents. I told him that guilt is a destructive motivator, at least in the long run. He replied that it actually worked well for him and he was glad to have it.

I also am sometimes motivated by guilt. Does it bother me because I'm more aware of it, or am I right in thinking that there are better motivations within reach?

It's a broad question because there are many underlying causes.

Some people have unrealistically high expectations for what can be accomplished. As engineers, it's easy for us to visualize the big picture of how things would look when they're finished, but forget all of the details and difficulties that must be overcome along the way.

Some people spread themselves too thin across too many projects, such that none of them see any rapid progress. I know a lot of brilliant people who could accomplish great things if they'd just make the choice to stop all of their side projects, learn to say "no" to new requests, and pick one initiative to be their main focus.

Some people think they want to deliver results and finish things, but when it comes down to it they actually prefer the craft part of the process rather than the finishing part. They'd rather write and re-write the same code 20 times until they've perfected it and generalized it for every possible situation, rather than ship an imperfect version that gets things done.

And some people genuinely aren't working diligently or effectively, usually because they haven't yet learned how. I see this a lot in younger people I've mentored: They aren't getting much work done, but they also can't figure out where all of their time is going every day. In one case, I worked with someone who couldn't figure out why they were so unproductive and exhausted every day until they enabled a time tracker on their phone and discovered that they were losing over 8 hours every day to playing on their phone screen. The worst part was that they weren't really enjoying it, either. They just got into the habit of wasting time on social media and it spiraled out of control. Needless to say, getting a handle on that was life-changing in terms of what they could accomplish everyone else in their lives.

Maybe it's just that he notices, as any introspective person might, that you just start doing the same damn thing over and over after 20/30/40 years in harness.

He probably should take up the piano.

I've resolved a lot of personal issues that are not supposed to be fixable and that makes it easier to feel like "Whatever I accomplish today, it's enough." I set goals for what I need to do next and I try to be realistic about how much I can actually do and I have made my peace with the fact that I'm only one person, I can only do so much.

Either the road rises up to meet me or it doesn't. There are parts of it I have no control over and if the world just doesn't want me to succeed at certain things, I simply won't through no fault of my own.

There has to be fertile ground for a thing. Thinking otherwise is often an oversized ego talking or some kind of baggage from broken mental models people get fed.

As a result there tends to be a mismatch between the expected and actual efficiency of the work. Even if the complexities are not one’s fault, overly optimistic expectations are. Furthermore, it’s simply frustrating that implementing seemingly straightforward ideas often takes so long. There is a conviction that there must be a better, more efficient way, and that one could obviously do better.

I suspect that there is a correlation with an affinity for abstract thinking, because abstracting from the details causes underestimating the required effort, perpetuating the mismatch.

Embracing the mismatch and giving up the expectations also means giving up one’s aspirations ("I should be able to do this") to a certain extent, which is hard if they are an integral part of one’s self-image.

Time alone not working helps this, meditating helps, anything that gets you away from the fracas of life. But also the best way is to develop things you care deeply about that have nothing to do with your job. May be a sick family member, could be a community organization, could be time to play the piano.

If you have some sense of your limitations, you no longer can really feel guilty about being lazy for this. It may be worse though, because then you can feel bad about your capability. Hopefully that is something you can just accept.

That said, I think distilling down this hard-won experience tends to lead to cargo-culting. Just look at "Agile" itself and how it's been embraced and then twisted by consultants into the exact opposite of what was intended by The Agile Manifesto to begin with. This stuff sells because people want clarity of what to do on a daily basis, they don't want to confront the reality that is no guaranteed path to make large scale software successful. Certainly some process and structure are helpful as long as they are specific to the problem at hand, and focused on the needs of the people actually doing the solving and giving them whatever air cover and cross-pollination needed for them to get the reps on the actual software.

Typically these types of projects happen in large orgs where there are incentives for middle management to avoid culpability for failure rather than to do what it takes to succeed (especially if it's a hard problem). In this kind of environment, process is often used as a cudgel for one group to protect itself by claiming "I did my job".

So to your question: how effective is The Agile Manifesto in practice? I think of it sort of in the necessary-but-not-sufficient bucket. Basically if you have buy-in to give a team this flexibility and autonomy you have a crack at solving a hard problem. Now it depends on the team and the problem: is the problem ultimately solvable and does this team have the chops?

When e.g. John Carmack talks about a technical topic there's a very long and very public record of the kind of experience that he has. It's reasonable to trust that they are correct, although one should still verify before betting their project/company/career on that piece of advice.

If I'm doing a more open ended problem like modelling something from scratch (I have boxes and arrows on a piece of paper but the edge cases are still a mystery) then it's something I'll exhaust myself on much sooner

I agree that it is possible to remain in a state of flow for "the standard industrial eight", but on occasions where I've remained in a state of flow for eight (or more) hours, the quality of the work suffers, and the following day is a total loss (as in "me no think good, think meat broken"), so it is better to keep to a more sustainable pace.

Even better, given that people are going to vary by at least as much as we vary in physical stamina, advice about how to learn what my own limits are, given that it's so hard to introspect?

The problems to solve still interest me, but changing diapers or getting something from the supermarket for my daugher before it closes has become important enough that may they to "disrupt"[1] my life anytime.

[1] in quotes, because I would not want to live without these "disruptions" anymore. The accomplishment of calming my baby daughter in a few seconds dwarves any of the hacks people still know me for.

I don't know what was first, but this certainly describes frameworks that actually exist.

https://github.com/unclebob/PDP8EmulatorIpad