* Depression and Anxiety

* High blood pressure

* Weight gain

* Not having any idea how to simply relax

* Friends were more or less entirely from work

* Loneliness

At the end of the day I didn't want to go learn more stuff. I tried like hell to just gain my life back and failed miserably. It wasn't until reaching basically the bottom that I found a couple things that helped me:

1. Blood pressure medication was a must, I'm still trying to determine if this is stress related or a genetic thing.

2. Meditation. I found I did a ton of thinking about the future, worrying about the past, and just in general not being able to live today. I still struggle with this, but meditation and mindfulness have helped me a lot in trying to be in the present rather than past or future (depression/anxiety).

3. Time off. Though mine was sort of forced and forced to be longer due to COVID-19, I found time off helped, but since it was unplanned financial concerns kept me stressed out and I'm still trying to recover financially now.

If an employer wants me to continue upping my game they will need to give me the time to do it while I'm working. Within reason. I'm not expecting like weeks or something, but I just won't give up my free time anymore, it's too important to my health.

The sad reality is I know this is something an employer will tend to look down on. But I've found that happiness is not work, and work is generally not happiness. You have to have happiness outside of work and they need to be distinct separate things. Work, fundamentally, is about paying for the things I need to live so I can enjoy myself. I've found I don't need fancy toys or an expensive house to enjoy myself. I don't have to live on a lot of money.

Anyway, a little long winded, but your comment hit a chord with me.

It's sad that this is what continuous learning for software engineers has come to mean. Don't do that! Learn to express different and deeper ideas in the technologies you already know. Programming is a huge world. Maybe you have truly tapped out line-of-business CRUD apps, but remember every line in the CS course catalog is a whole universe unto itself.

Operating systems, distributed systems, databases, graphics, embedded systems, HPC, etc. Pick a layer of the stack, understand it, and move it forward a little.

You'll notice that many of these worlds have completely skipped the Javascript framework treadmill, and K&R C from the 1970s will get you a decent part of the way there.

I mourn the time I have to spend re-learning CRUD because it distracts from this mission.

I was there a little over 10 years ago at 35. I belatedly learned how to play the game. Until my current job, it was all about resume driven development and job hopping the minute my salary or what I am doing at my current job got out of whack with the market.

I wonder if this will keep me stagnant in my programming chops. But at the same time I realize that expanding the chops is diminishing returns for my life from all angles, including satisfaction and finance. I have hobbies, families, communities that I serve and are expanding other non programming skills.

That being said, at the same time I also kinda don't know what is fun anymore about programming. I think for me, creating real stuffs that real people can use is always fun, but at the same time I don't have ideas. Many (useless) ideas are already reiterated over and over again by people posted on Github/Reddit.

I tried to go deeper into a specific implementation, like for example database engine or compiler. But I realized that wasn't as fun as I thought it to be.

In terms of programming, I always liked learning programming languages, but it gets old real fast. Once that is over, I don't know what else should I do. I'm thinking of learning OCaml next. Or maybe I should try other field of programming like game development. Or maybe I should just be content not doing any programming related hobbies anymore and just stick with my other hobbies.

This is a side effect of having non technical managers. They cannot judge your technical skills beyond a certain point. They can judge your people skills and domain knowledge. They reward improvements in what they can judge.

The above doesn't apply in tech companies and in tech hubs. It applied to me when I searched for jobs in a relative backwater only (and as somebody who wanted to advance technically it was frustrating).

This is why I think you'd be more likely to find expert beginners in Maryland or Singapore than in San Fran or New York.

I feel like the article and the hype cycle push us towards the latter rather than the former. Which is awkward because that seems like a good, concise definition of expert beginner: someone that has 1 years experience repeated 10 times.

Of course, it can pay well to be certain kinds of expert beginners.

This is definitely my feeling. After awhile, you've created most the types of functionalities and at some point, you start to see a lot of the same functional outcomes from shifting technology and shuffling abstractions. At that point, it's literally just the tedious effort of learning some new abstraction someone decided to create and some sensible flow within their set of abstractions from start to functional product. You end up dealing with slightly different processes that require tedious time investments to suss out.

Sometimes it's a useful shuffle. You gain a more rapid development process, things are easier, you gain additional functionality than previous approaches for similar efforts. A lot of times it's literally just "ah, new shiny" and you can't be bothered to deal with "ah, new shiny" with your free time as you felt you had to as a beginner/novice (spending several weekends and evenings or so of your free time). You've also, through your career, been forced to deal with these transitions due to someone else's decisions and been burnt multiple times learning to do the same thing slightly differently because someone else in charge or a group with momentum was sold by new shiny.

At some point you learn to assess new shiny before you invest time into it. You've seen the marketing tricks, you've seen the tech industry dazzle with ambiguity/complexity tricks, and you frankly would rather go exercise, spend time with family, or do anything else but be trapped investing personal free time due to some business scheme. Unfortunately, a lot of other people haven't learned to objectively assess new shiny and fall into the marketing and ambiguity traps. It may be business leaders, it may be younger developers eager to 'improve' with new shiny because it's going to be "paradigm shifting," etc. Ultimately, momentum builds and you either join the club being sucked into new shiny (where a lot of resume driven development starts, IMHO) or are left behind.

It's amazing how people continuously fall in these silly traps. I'm not saying all change is bad, there are some improvements and some tech has to be kept current to remain interoperable with other tech. I am saying that a lot of it is an absolute waste, and this is why you have these 'Expert Beginners' -- those who realize outside of tech, the vast majority won't see imporovements and inside of tech, the improvements for adopting a new technology are often questionable (if even existent).

I don't know, maybe development should be individual thing. Less bureaucracy, less politics, you get to control more. Besides other human can be finicky.

These days I rather be full stack dev.

Good thing is technology, due to non stop advancement, inherently enables individual to do more and more.

The truth is organizations only respect you for the things you do well and that an organization thinks is important. (So if you are great at documentation for example, and the organization doesn't prioritize that, don't be surprised that no one cares. Etc.)

Doing things you are not very good at or don't have time for only damages your brand. Saying no is also a way to test the waters about how much what you are doing is valued. Imagine part of your job is X, and someone says: "Can you do Y?" You say: "I can't I am working on X." If they say do Y instead, its a hint that either X isn't that important or people don't think you are valuable to it. Find that out!

People will waste your time with meaningless or unimportant work. It is one of the ways that they tell you that they don't really value your contribution. Or not. The way to find out is to try no.

The biggest improvement I ever had as a developer came from reimplementing the same thing in Lisp and OCaml that I previously done in Java. It was quite eye opening to see how much more concise I could be if leaving the mainstream languages and started to use something more advanced (also niche at the same time). After having discussions about this with me peers who completed formal education in CS, they explained to me many concepts that I was not aware of and turned my attention to functional programming and ML languages in general. As of today I am even more convinced that doing the same thing in different languages / environments helps me understand the problem domain better, select the right tool for the job and become a better engineer.

> The older I am the more I'm convinced that development is not individual thing - it's a team sport.

I agree. We usually do these implementation exercises as team work.

> they realize that that to learn how to do the same thing with 167 technologies is not a real development

is quite an arrogant view to take on new technologies. It assumes that the sole reason people use new things is a combination of ignorance and boredom. There may be some of that involved in some cases, but even re-inventions of the wheel usually come with a fresh perspective and incremental improvements over the last time. More importantly, knowing the technology of the day allows you to relate to and collaborate with others, which is most certainly not a waste of time.

Turning down applicants who have the above mindset isn't ageism.

And maybe because they realize that the majority of those 167 technologies only exist because someone said "Making frameworks and generalization is the only reason I manage to keep doing what I do." [source: https://news.ycombinator.com/item?id=13734009]

Yes! A few months back I was feeling quite burnt out over this feeling.

Taking a step back and focusing on a wider variety of work / hobbies / projects did wonders for my work motivation and ability.

It seems to me that taking on a larger, wider variety of mental tasks actually improves ones ability to focus on a single one, instead of spending all energy on one task (or job).

the 4h has to be shared. everyone on the team has to be in menstrual synchrony, so to speak. this type of work requires one to get "in the zone", or achieve the "flow" state. everyone has different biorhythms and won't even maintain the same time schedule on a daily basis or even weekly basis.

in an 8hr day you might get 3-4hr of good performance. yes you can do better, but not on a sustained basis. yes more hours per day will give you more but after 8 it really starts to become a diminishing returns thing.

if you tell people to only do 4hr of work, the output is going to be 1-2 hr of efficient work.

you are basically claiming it's a team sport but want to apply a principle that would only work for you personally. now if you can hire only people "like you" then you're golden. or, if you can pay (say) 2-5x market, fire quickly, compel people to have a very specific training-like schedule with execute-or-GTFO practices, have a high demand but high performance environment, only hire high experienced devs, then you might have something. it's not generalizable to the extent that it is usable advice or recommendation.

lastly does your 4h of work include communication and coordination functions? if so, it's reduced to 2h of work.

Idea: what we're actually measuring is the speed of human reasoning vs the business value of time-to-market.

I agree that doing the same thing 167 times is real improvement. Though I don't believe that to be the reason for the expert beginner.

I've seen countless people learn that one technology just well enough to scrape by. Not a bit further. And going further can be done during work hours.

I think this is a bit of a loaded statement. Phrased this way, who could argue that learning to do the same thing with 167 technologies is real development? If you listed out the technologies, I'm sure you'd get plenty of responses from people who disagree that they actually are doing the same thing. As a frontend dev, the technologies I'm aware of all have vastly different developer experiences and tradeoffs.

Part of your duty as a professional is to separate out the hype from the useful.

I just got done wit a brutal job search. I call this attitude "losing the fear." I would not be so sure the next 100k job is waiting for you if you are not improving yourself.