I think going deep on something is the key. It lets you keep learning without getting bored and needing to jump ship. One of my pet peeves is how programmers think "keep learning" means "learn another programming language". Not that that's bad, but after the twentieth or so, . . . instead try learning something "adjacent" to what you enjoy & do well. For example for a Ruby+JS web developer: read some HTTP RFCs, play around with SSL certificates, learn some admin/devops skills, get really familiar with some part of modern JS/HTML like your framework or build system or HTML5 canvas or video, read the Rails Github issues list and fix a couple bugs, try writing your own gem, try writing your own gem with some C/Rust implementation, go fix all the n+1 query problems in your app, learn how to use CTEs and lateral joins, learn some plpgsql, write your own Postgres extension, etc. Or pick something adjacent-but-non-technical, like marketing or SEO or sales or financial statements. Remember that careers are long, and learning pays compound interest. There is no reason to get bored!

This really resonates with me.

I'm a marketer who has become more and more technical over my career. The amount of opportunities that has unlocked have really been worth it for sure, but it also simply lets me be better at my trade than those who do not have those skills because I see connections they may not, and I can implement those things independently or with fewer resources than others.

It also frankly just makes things more interesting, because when I think I've reached the bottom of a rabbit hole and risk getting bored, suddenly there's this new tunnel branching off of it that I can explore, and before I know it, I'm delving into expert-level problems of a part of my industry I've never considered before.

This article makes fundamental errors. School performance is NOT a great indicator of intellect. The most successful people I know did just enough to get by decently in school and spent the rest of their efforts on activities that made them happy or were more productive. People who drove themselves crazy working as hard as they could in school generally didn't get anywhere in the real world.

>People who drove themselves crazy working as hard as they could in school generally didn't get anywhere in the real world.

I think these are the people the author is referencing. These students did amazing if measuring by GPA, but did so through hard work and a lot of thinking. Got praised for GPA related achievements which reinforced their over studying/thinking behavior, which leads to the scenarios the author describes.

The most successful people you talk about likely wouldn't have the issues the article addresses.

Anecdotal evidence. Data shows success in school correlates with career success.

Its mindnumbing to learn the extraneous details about something that's basically understood. I dont want to master x86 assembly when I already get the concept of what it represents. I want to learn new concepts. Make a lambda based computer for example.

Browser development is the worst. Hacks and compatibility details galore. I hate the fact that to get into front end development I would have to master how to get around someone elses mess.

I would piggyback on your answer to say that learning those adjacent skills will also help you work on your process of learning in general.

You're less likely to get stuck and give up because they're adjacent, and then when it comes to learning something not adjacent you're already a more experienced at learning and organising your thoughts when it comes to tackling a new problem.

The problem I have with this, is that if you don't get to use your new shiny tech in your job, over the years you tend to forget the knowledge, at least that's the case for me. Does everyone else have eidetic memory?

I found myself having to look up syntax and idioms of languages I was productive in a decade ago.

This part was also key:

"Solution: Try taking a 30,000-foot view of when it’s worth tolerating some boredom to collect easy wins when it comes to your overall success. Instead of attempting dramatic change, decide when tolerating short periods (a few minutes or hours) of boredom could have a very beneficial impact on your success. For instance, devoting 5 hours a week to an activity that’s monotonous but lucrative. Additionally, make sure you have enough outlets for your love of learning across the various domains of your life, including your work, hobbies, physical fitness, understanding yourself etc."

Doing work that's lucrative yet monotonous is one of the biggest struggles. I have in front of me a great strategy that I know will work, but I'm avoiding putting in the elbow grease.

Anyone know of a book that goes into this in detail? I know I'm procrastinating more by looking for a book to solve this, but at the same time, when I understand something thoroughly, I do it more often!

Not quite exactly about "lucrative yet monotonous", but The War of Art is definitely an extended meditation on "putting in the elbow grease". It's not a manual of techniques about how to get things done, but it is inspirational for getting out of your own way, shutting up, sitting down, and writing.

It's written by someone who mostly writes movies, but it applies to anyone who does anything remotely creative, where your project has a lot of uncertainty and many opportunities to stall or talk yourself into giving up.

Highly recommended.

Great book - I love that one, anyone who creates should read it (code, writing, art, marketing) - I agree!

Agree that it's a meditation/mantra-like book that can be read monthly to refocus.

hey thanks for suggesting this, based on what I've read so far it's extremely applicable to my situation and is the sort of thing I've been needing to read for a while. hopefully i can intuit the wisdom at this point in my life.

Persistence is a skill that needs to be trained just like all skills, intellectually gifted people tend to get little training in it because they learn stuff fast and thus don't get the usual amount of training in it like others, so what you need to do is pick a thing you want to do that's boring and then measure the time of how long you manage to do it in one day, then you reward yourself with something, next time you try to do it for longer than last time and if you manage that then you give yourself another reward. It's just a skill, it's hard to train but train it you must if you want to be good at it. There is nothing more to it sadly, its a simple problem with a boring simple solution, you just have to put in the hours and train that skill.

This was painfully visible during first year at university - all the gifted people who during high school didn't have to learn at home at all hit the wall. They simply couldn't manage like that anymore.

Many somehow switched and started learning/working on assignment, those who didn't didn't make it.

> Anyone know of a book that goes into this in detail?

As cheesy as it sounds, the best book I've found on this topic is Getting Things Done.

I struggle with a lot of the issues in this article, and resisted that kind of thinking for years, but learning how to break up the insane overload of ideas and things in my head and bring them into manageable chunks, living in an outside system, has really really helped.

Great recommendation and good to be reminded. Have been reading it here and there but need to finish it and get it done.

Check out "Time Management for System Administrators" by Thomas A. Limoncelli.

It is showing it's age technology wise, being published in 2005, but a lot of the fundamental principles still apply.

Sounds niche, but that could make it even more useful - will check it out!

I haven't read but just a summary of the book but even that was helpful in letting me reframe some of these issues that I struggle with.

https://www.amazon.com/Mastery-Keys-Success-Long-Term-Fulfil...

The key message that stuck with me was that the early stages of the mastery slope are exciting because of how much new knowledge we gain. However, most of life is spent in the plateaus, and learning to love the plateaus is key to finding persistence and self discipline.

Great recommendation, going to buy it.

From what I’ve read on it, seems to take a Zen-like approach, which I appreciate.

Try book "Mastery" by George Leonard.

https://jamesclear.com/book-summaries/mastery

Full text [pdf]:

http://index-of.co.uk/Social-Interactions/Mastery%20-%20The%...

All jobs have some amount of grind. Being able to acknowledge its going to suck and push through it quickly can be super beneficial to your career. It's also one of the reasons why I encourage those in high school or college to try a non technical job first. Learn to appreciate doing monotonous tasks well.

As a manager of a dev group, I've migrated away from trying to hire "10x developers" and now optimize for "intelligent and persistent".

The "10x" developers are seductive, and can supercharge a project into getting version 1.0 off the ground in months instead of years. However, each one we've hired has left us worse off than before once they got bored and left us in the weeds trying to piece together what they had done.

Most of them suffer from "shiny ball" syndrome and are constantly dismayed by the complexities of the real world. The real world is a grind, filled with edge-cases, filled with needing to make 1-off exceptions, etc. These types of developers tend to hate that, and prefer the abstract beauty of their elegant and simple solutions....and when the real world crashes into their elegant creations, they get 'burned out' and jump ship.

I'm not blaming them, its just an observation. These 10x developers can be a godsend to a brand new startup, but past a 1.0 product, they can subtly turn into a liability fairly quickly.

I think there's "10x" and then there's real 10x.

Fake 10x: Turns out lots of stuff quickly but it crumples under edge cases and has non-obvious tight couplings that keep biting you. No one else can make changes to their code. None of their stuff can really be used when they leave the company, but they can fix it really fast.

Real 10x: Is able to explain what they did and why bugs happened. Easy to follow along in their code, you get the impression the job was easy. You constantly find yourself turning to their old solution, when it really matters, rather than the new way everyone's trying to migrate to. Suggests ways their existing system can handle new business use-cases with only a trivial modification. You keep trying to improve upon their work but keep concluding that there was a good reason for all their decisions.

Depending on the context, someone might be referring to one or the other.

Exactly. There are cowboys and then there are master crafters. Both will rapidly produce awesome results, but the cowboy's results are messy, fragile and temperamental, while the master crafter's results are robust and easy to understand.

This. I understand 10x as a kind of person who creates MapReduce and writes very convenient abstraction around it that anyone can use and become 2x.

It takes repetition: code is a liability. The less code you produce to solve your problem, the better.

OTOH there is a cycle I see everywhere, all the time:

* A first generation of anything is bare-bones, with multiple deficiencies and corners cut, with important parts held together by duct tape.

* A second generation of the same thing tries to fix everything, adds reams of missing features, and ends up being an over-complicated, bloated monster [second system].

* A third generation of the same thing builds on the knowledge gained so far, refines the ideas, throws away all the unneeded parts, and organizes the few necessary parts elegantly and reliably.

(I use indefinite articles before "first", "second", and "third", because each may take much more than one iteration.)

Your hyper-productive developers likely produce the first two varieties. This may still be very useful, if they allow the business to grow. They as well may introduce too many technical problems and operation costs, and thus be detrimental to the business, too.

[second system]: http://wiki.c2.com/?SecondSystemEffect

(Edited: typos.)

That's not a 10x developer if they don't know how to write maintanable software, you just thought they are.

The dev you describe sounds like a junior who can crank out code at high velocity.

This is why the 10x is a unicorn. HN likes to shift the definition every time it's found to have some quality we don't like. In the real world there is a broad spectrum of devs and their capabilities. Each one has strengths, weaknesses, areas of expertise, and character flaws. You'll basically never find one that just blindly produces 10x the code of the rest of your team without some downside.

They are Unicorns but you know them when you see them. Cranking out code at high velocity that looks and feels right. When they don't know how to do something they actually research and look at the field. If no prior art exists at all (they frequently find themselves in this situation) they're already on their third iteration before anyone else has a prototype - even they can't get it perfect the very first time.

E.g. If they previously wrote compilers and you tasked them with graphics you'd see a book explaining affine transforms on their desk. Or parsing theory for the reverse transition.

A key part however is the ability to switch between fields. I've seen people I thought were 10x completely fail when tasked with something new.

I reckon that if there's such a thing as a 10x dev, they'd act as a force multiplier rather than a faster assembly line worker. Fixing architectural problems early raises the productivity of everyone who ever has to touch the code, as does setting up practises like code review and automated testing, and as does culling bad features early on.

I agree and it might not be possible to recognize such a person as a 10x dev.

Imo, the whole concept is idiotic and serves nothing.

Of course it is possible for one developer to be better then other, but it is not necessary fixed. It changes during lifetime of same person, depends on technology, experience, type of project and other factors.

Meanwhile the typical use is to look at some stereotype you have in head that has nothing to do with the project or position at question and then wonder why it did not worked out.

I've met someone who I'd call 10×. I've worked with him. He once wrote a usable spreadsheet, with a fine set of formulae and an entirely plausible UI, in an evening and a night.

His code had major issues, but that's not to say that he couldn't write software. He could, in a manner completely different from me. Amazingly well, yet frustrating.

Above a certain level, one developer isn't universally better than another. It's not linear any more.

He's a CS professor now.

This is so interesting. I have met many people that others considered "geniuses" because they solved hard problems and got things done fast. And then 3 years later, people still complain about having to deal with "[Name of Developer] Code". I guess if you move fast and write code that others can't read, it's easy to get labeled a genius.

Yeah, I kind of moved of definition of good code from cool-smart-novel approach to something as simple as possible, that almost anybody can pick up, maintain and improve. This has various aspects - cleanness of the code, comments of algorithms/edge cases, overall structure, modularity etc.

Syntactic sugar can't impress me anymore, unless it comes with significant performance gains or compress the code significantly without sacrificing readability to average Joe coder (this is important part). Actually I prefer 1 page of simple clean code to 1/2-liners that do it all, until they don't. I guess I am getting old.

> And then 3 years later, people still complain about having to deal with "[Name of Developer] Code"

You're saying their code was so good it survived 3 years of real world use and project evolution. That's extremely rare.

Counter intuitive, like the "put the armor where the bullet holes aren't" story about WWII bombers.

The best way to get a 10x developer is to have a productive senior closely mentor 10 juniors - pair programming, code reviews, testing strategies, deep dives into architecture, bi-directional knowledge sharing.

It's a case where the whetstone sharpening the knives also gets sharper by virtue of what they learn from the juniors they mentor.

Unless you can coach and pivot someone from that "must make everything perfect" mentality to one where they can take a more pragmatic approach to things.

This is really hard. Really hard. It can take years to get an engineer to that sweet spot.

When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.

This is part of a larger spectrum of developer preferences: openers, sustainers and closers.

Openers want to create new things, they love a blank canvas. Where some people are scared of this, they thrive in a place where you can lay down rules, define parameters, and create structures that are a good fit for the problem domain.

Sustainers like to work within a project that's evolving, but largely defined, where they can get a lot of things done and move the ball forward. They may create more work along the way, go on excursions, but the overall direction is roughly towards the goal. They have to make many compromises along the way.

Closers like finishing things, closing out bugs, wrapping up features, taking care of a myriad of loose ends and "TODO" type tasks. They're interested in completing work, not creating more work. This is where you have to make harsh judgement calls, implement ugly hacks, anything to wrap things up.

It's rare you'll find someone who excels at or even likes to do all three. We often have our bias.

I disagree that "closer" is a distinct class. It's a necessary aspect in any class. In most companies if you don't "close", you get fired or put on a PIP (and you don't get coffee). There is another class that at some companies where closing isn't necessarily expected: "tinkerer". They just mess around with various projects to learn and make suggestions, but they don't have to close to keep their job.

I'm trying to distinguish between responsibilities and obligations, which you're forced to adhere to, and affinity.

Anyone can close if they're forced to, but some people actually like it. Clear objectives, solutions need to be focused, etc.

I've never heard it stated that way, but I can strongly identify with this. After 18 yrs in the industry, I am finding more and more that I enjoy improving much more than building.

"All jobs have some amount of grind"

Almost all real jobs are mostly grind.

Even startups ... a good one, is 99% stupid, annoying details, some of which would be fun if you were not so busy.

Airtable.

What a cool app! In the news today.

"But I have to get fing xyz done fing now, so abc can ship out to Hong Kong before 5 hurry up!"

So there's not time to search, explore, try it out, it's just a very rapid short query to figure out the essential basics and move on.

Early stage is all a grind and there's nary a moment in between.

Apologies for the language.

learning to appreciate monotonous tasks is too zen/enlightened (like someone in another thread weeks ago saying they enjoyed washing to dishes) and therefore sets the bar too high. but learning to persist and endure (by way of coping mechanisms e.g. music, short breaks) is very possible.

I definitely don't want my team to appreciate boring tasks! I want them to persist, endure, and then automate.

The person who grinds through the boring stuff while thinking about how to automate it so they don't have to be bored anymore, is the person I want to hire.

The nature of the work doesn't allow that. Coding takes all your thought - even when it's boring and monotonous.

The comparisons being made to washing dishes aren't realistic.

Sorry for the ambiguity: I didn't mean literally at the same time like washing dishes while dreaming of dishwashers. I mean, like, do some boring coding drudgery one day/week/month, and then the next day/week/month do a bit of dreaming and whiteboarding of how to automate a better world, and then we can prioritize and make time for the automation work to make the better world a reality.

The important part is noticing and recognizing things that are ripe for automation, rather than accepting the shitty world as it is and continuing to suffer through repetitive work that could've been automated.

I agree with this, boring & monotonous code tasks are basically excruciating because you've got to concentrate on them hard and yet you'd rather be doing just about anything else.

I've done some refactoring work that didn't take any more mental effort than dish washing.

Sure. Is most work like that, though?

There's also different kinds of boring/tedious though. I'd argue it's much easier to learn to enjoy washing your dishes at home than it is to enjoy slogging through trying to grok horrible legacy code. Maybe that's just me though.

I agree. Especially if there are other teammates who defend the bad codebase because of their association to it.

Nobody should claim washing dishes is inherently wasteful or pointless. Legacy code on the other hand, comes with a lot of social pressure to just layer on more debt.

Maybe I’m just weird but I’ve never really defended my code because I never found defensiveness to be helpful for moving projects forward. In fact, most of the code I’ve put out in my career has been rushed under pressure to deliver something fast so most of the time I’m distancing myself from the work usually saying “that wasn’t written by me, it was my evil twin that comes out at 2 am.” Trying to fix the problems of the past that keeps your codebase from improving at a better pace isn’t something shameful to me as much as a matter of pride - that you have learned from your mistakes and are not above reproach. The best stuff for me is what I do after iterating many times without fear of breaking anything though and that’s exactly what you would hope from a codebase matured through TDD.

That's fair. When I say appreciate, I mean the results of the grind. Washing Dishes or any type of cleaning isn't fun, but finding coping mechanisms (zoning out, music, etc...) you can enjoy the results.

I agree. A lot of the devs I know who had non tech jobs have a better appreciation for business decisions and management than do those that just went into a dev job.

My conclusion to the BS inherent to any job is this: get your "brain food" outside your job. Start today if you haven't been doing this. It's fine that sometimes we get to learn interesting things while on the clock, but we have way, way, way less control over what we learn. I have followed this strategy for some years:

1) Look for a low-stress job with manageable time. In tech this doesn't mean "low-pay" as well. I'm being paid quite well and I will never do more than 40 hours a week.

2) Treat that job as your day job to pay the bills, and learn whatever you want during your (relatively abundant) free time. Learn a new programming language, learn about any other topic of computer science or software engineering, get any skill not related to your job, get a new degree, whatever. It is up to you whether you want to learn something that will make you more money in the future or not. Beware: open source projects are nice but, unless it's a project of yours and yours only, you have less control over what you do, and in that sense it's a bit closer to a job.

It's also true that mundane tasks will make you much better at your job, but TBH, while that's helpful (and helps building a career more than most young people would think), it's not something that important to me. I'd rather be good at things that are important to me. A job is there to pay the bills and nothing more; anything else is a bonus which I won't take for granted, and this includes the social aspect of the job.

I used to think like that but worked towards getting a better job.

My work has millions of dollars of DNA sequencing equipment, lab experts and a states / nations worth of patients data. No side projects for 7 years and I am ok with that.

I can also take days/weeks off to read or experiment but have been grinding lately.... with a family and meetings etc running a team of 3 I basically have to take any chance I have to crank out code.

I hate to say this, but I've been finding Nicotine to be very useful for dealing with anxiety, restlessness, and boredom with rote tasks.

I've had some issues with depression and anxiety that I've been managing with my doctor, but there are still times where extreme stress can cut through the drugs and still give me some issues (work has been very political lately).

I started craving a cigarette, which is weird because I was only ever a cigar smoker, very infrequently at that, and gave it up (very easily, given I usually went months between cigars) years ago.

So under the guise of "if you're craving potato chips, maybe you're low on sodium", I bought a small, very low dosage, disposable e-cigarette at a convenience store. And the last two weeks have been some of my most stable, calm, consistently productive weeks in a very long time.

Now, I know Nicotine is very addictive, and I have no plans to go back to smoking. I'm planning to switch to a nicotine patch, as the vapor is irritating to my throat and there is still some concern of increased lung cancer risk. I think a patch will be easier to meter out the dosage, too, rather than puffing on a pen every time I feel like it. Sum total, I think I'm receiving a net benefit right now (it has also calmed my snack cravings and my blood pressure is now at a 5-year low).

Anyway, it's dangerous to self-medicate, but most people do anyway, whether it's with alcohol or bad relationships or the internet, and it's not my job to tell you what you can or cannot do. Just trying to relay that there might be some decision tradeoffs that might leave you with a net benefit.

Nicotine was one of the few nootropics that had real measureable positive effects in gwern's testing. Unfortunately it's addictive as hell, but nonetheless, you'd think that as much as we research into opiods and other narcotics, there would be more effort to find safer forms of nicotine or nicotine derivatives.

https://www.gwern.net/Nootropics

Genuine question based on personal experience, is nicotine itself addictive or is it nicotine + method of delivery?

Cause as someone who smokes cigars (don't inhale, do absorb nicotine via the mouth lining) I really don't find them addictive at all, that seems broadly the case with most cigar/pipe smokers we generally aren't addicted to them.

And yet cigarettes are obviously super addictive, so is it something else in cigarettes that's adding to the addictive nature? Or inhaling into the lungs, where presumably you'd get a much faster hit or higher dose?

I've been a daily nicotine gum user for years, and I'd say I'm addicted. I've tried to quit several times. I'll kick it for a couple of months, and then I'll have a stressful week and I'll buy a box. Then I'm back on it for a couple of weeks until the box runs out. And sometimes I just go buy another box.

For me, it's not addictive in the sense of "I experience withdrawal symptoms", but I have very strongly conditioned habits with specific triggers. Nicotine spikes my dopamine, and also improves my concentration and memory when I'm using it. Which makes me like it, and also chemically encourages situational cravings.

As an example, I chewed it when I was driving to work every day for a while - and now I think about it almost every time I drive anywhere. It's not really an "I need a piece right this second" kind of feeling for me, but more like a "Man, some nicotine would be awesome right now" kind of feeling.

One aspect of the addiction that I think many nicotine users would agree with - it's not an instant process. I knew I was developing the habit long before it was a full-blown addiction. I kept telling myself I wasn't going to get addicted, that I was stronger. Turns out maybe not so much.

Another Gwern link: https://www.gwern.net/Nicotine

Highlight: "Wikipedia summarizes Guillem et al 2005 as "Technically, nicotine is not significantly addictive, as nicotine administered alone does not produce significant reinforcing properties" - the addictiveness coming from MAOIs (eg. Khalil et al 2000, Khalil et al 2006) & possibly other compounds present in tobacco"

So I'd expect cigars and pipe smoking to be addictive. My personal experience is smoking cigarettes occasionally (average less than one a day), and I wouldn't say I was addicted either.

My current hypothesis for why cigarettes seem more addictive is frequency. Searching "cigarettes per day average" turns up estimates mostly around 15 per day; most cigar/pipe smokers aren't anywhere near that.

(Disclaimer: I am not a doctor or scientist.)

As Pete_D linked below there is now some evidence questioning the addictiveness of pure nicotine, however for ethical purposes these studies are generally done using animal models, most commonly rats so YMMV. Animal studies don't always correlate 1:1 to human studies. The majority of studies I have read still find nicotine more addictive than placebo. Definitely traditional cigarette products, many of the manipulations done in treating most brands of cigarettes (the exception being brands marketed as natural i.e. American Sprits) made them more addictive by adding additional constituents and potentiators. In the combustion of tobacco products as well you have the active constituents bound to the smoke molecules, which are larger and therefore more absorbed in the lungs. So yes you would be getting more effect from lung-inhaling a combusted product. Vapor products have a much smaller particulate size so are mostly absorbed by the mouth and upper airway and much less lung-dependent. The other issue that may help to influence addiction is that there is some evidence that exposure to nicotine while the brain is still developing, leads to a tendency to use higher doses as an adult. This may translate to developing brains get used to this powerful nootropic and are more addicted as adults, as speculation, it would be hard to design a study to test this. In terms of vapor, freebase nicotine has traditionally been used in vapor products, these tend to show slower absorption and more even blood levels over time. What Juul innovated, and why their product is so much more effective that previous electronic cig-alikes (like Blu) that use freebase nicotine is the development of nicotine salts that allow for increased peak absorption more mirroring the absorption curve of a traditional cigarette. The relative addictive potential of nicotine salts vs. freebase nicotine has not yet been scientifically investigated. The World Health Organization and other health organizations that tend to prefer harm-reduction and scientific objectivity estimate vaping is at least 95% less harmful than tobacco as a nicotine delivery system. (Source: can cite links, RN who reads journal articles for fun. Smoker since 14 y/o switched to vape full-time almost a decade ago.)

Since you say you're on a very low dose, may I suggest gum or lozenges? I tried nicotine patches for focus a while ago and found that even the weakest ones were far too strong.

Did you try cutting the patches in half?

I didn't - I'd heard it was dangerous since breaking the membrane meant you'd absorb the contents a lot more quickly at the cut edge.

I don't think that is a helpful comment, especially considering I did say I am working closely with my doctor to monitor my health and mood.

The practice of medicine is not actually that hard. It's all about risk profiles and benefit tradeoffs. The Lexapro I have been prescribed for my anxiety and the Advair for my asthma could very well be more dangerous for me than any trans-dermal Nicotine patch might be.

Our Food and Drug Administration has decided that it's relatively safe for me to buy Nicotine in whatever amounts I want without any more restriction than me being more than 18 years old. They've decided that Advair and Lexapro have risk profiles worth forcing me to go through my doctor before allowing me to have any.

We have thousands of years of data that shows Nicotine doesn't just randomly make you want to kill yourself. We have a lot of evidence that smoking tobacco can increase risk of cancer, and that the additives in commercial cigarettes can increase that risk a lot, but that doesn't apply to Nicotine specifically. There is some evidence that any sort of lung irritant can increase the risk of lung cancer, so even vaping might not be completely safe, but neither do we know the magnitude of that risk, especially separate from the many other irritants we're exposed to on a regular basis.

I'm not trying to advocate for using Nicotine. There is a risk of smokers pointing to information like this and saying "see, my disgusting habit is not that bad". That's not at all what I'm saying. But just because I don't have MD after my name doesn't mean I can't make informed decisions on my own about my own treatment. I'm just sick of this infantilizing concept that intelligent adults can't figure out a few things on their own.

While I whole heartedly agree with your logic and opinions on this: have you met many adults? They are awful at critical thinking. It strikes me that this is indeed a good chunk of why health/medicine is hard. Some people literally can’t be trusted to evaluate complex decisions effectively. So you end up with highly regulated practices, and those people who have the mental capacity are left out.

I’m a cancer patient undergoing treatment. Please be careful, you don’t want this.

I’m seeing how a few sprinkles of VBA can make an .org so much more efficient than trying to bend management to green light an entire new web app system written in a ‘real’ programming Lang

Totally. When you're new to the profession it's like you have this huge shiny new hammer and everything looks like a nail, so you want to build new custom software to solve every problem, because it's fun.

But I feel like after working on enough legacy systems you come to appreciate how crippling technical debt and over-complexity can become to an organization. What was an exciting and fun project for the creators is now the daily hell for a whole department of people.

The downside is I feel like the maturation of software as a whole is at a point now where it's diminished my ability and desire to pursue entrepreneurial ideas. There's so many powerful existing systems that can be glued together that the hassle of making something from scratch rarely seems worth it when you can get something "good enough" without custom code. On the one hand that's great for business efficiency and non-tech companies but kind of shitty for us developers who love to build stuff from scratch.

I concur. The tedium of maintaining somebody else’s crap code in an obsolete language is an invaluable learning experience for new devs. Also, it’s hilarious to listen to the whining.

Sometimes I feel like whining about someone else's crap code is enjoyable in itself.

Until you realize it's code you wrote. Happened to me when our children were little. There were large parts of a system I'd written, sleep deprived, that I had no recollection of writing. Version control said I did, but I didn't remember it.

That can make it even better, particularly if you can remember why you were making the decisions that you did.

Yes! It's actually great -- you can rant as hard as you want because you know the author won't be upset.

Oh but the author is upset, just with themselves

The property of finding their complaints hilarious would make me deeply question your technical judgment & maturity while also being certain you lack leadership skills. I’d also worry you would dismiss ideas of junior team members regarding how adopting new tools could better solve business problems, which is critical even in situations where you’re constrained by stability requirements of a legacy system.

parent comment could be interpreted many ways but heres my take.

there are many types of humour one can appreciate: https://www.huffingtonpost.com.au/2017/07/19/there-are-nine-...

If someone can't lighten up and find humour in life, i'd say they are mature enough to graduate life and go on to the next realm lol.

> But in reality looking back I see that a lot of that sh*t-shoveling has actually made me much better and wiser at my profession,

I agree with this to the point that I seek out the stupidest, most concrete, least automated solution as a point of reference before I build anything smart.

Im a chem engineer by degree, worked in a factory.

After got a job designing in Mechanical Engineering, got another job in a different product, finally I'm in Electrical Engineering.

Being a self taught programmer for 10 years, I've found this variety in experience allows me to engineer pretty much everything from embedded to packaging.

I might have been very talented at making airbags, but I would not be controlling electricity if I stayed in that one job.

I felt the harder things to convince someone(including self) is to spend lot of time to learn the "other skills" (mentioned in the article). People do try to improve their "other skills" to some extent but that may not be enough. Feedback loop for seeing the impact of the "other skill" is long and it is harder to measure. So one doesn't know if one has learnt enough.

Regarding boring. I have found that sometime if we zoom out too much things are boring. Life is boring if we think everyday we just wakeup, work, sleep. When we zoom in and look at the variety and try to understand life becomes more interesting.

Zooming in too much also can cause boredom. Zoom into the coding too much and think I am just typing another ifThenElse or while loop or some keystrokes it can be boring too.

Usually I have found, for management work zooming out makes it interesting for me. Technical work usually is interesting at the level I see it.

Like some people mentioned listening to music, doing something else when the work look boredom can also keep one going with passion.

The other challenge is once the work becomes routine, one starts feeling anyone can do it. One starts feeling am I justifying the money I get for it?

I spent most of the day trying to get access to the new Instagram API when all I wanted to do was getting some data for my ML model.

I've found that probably over 50% of my work as a developer in bank was about dealing with security:

- Getting credentials to some external system with which we need to integrate

- Learning how their authentication scheme (Kerberos etc.) works

- Finding workarounds to not having admin rights on my laptop

- Finding workarounds to bank's firewall (a lot of package repos were blacklisted)

- (the biggest one) Having to deploy the app into dozens of separate unix accounts, because, according to security "no one account should have access to all this data"

Over my admittedly not that long career, I've found that minimizing the overhead that the daily grind creates in your productivity is by itself an art form. The grind isn't avoidable, but you can be more or less productive despite it.

As an example, I recently had a project where most of the drudgery was changing one line, testing the whole thing (including manual tests), realizing another one-liner was needed, doing it all again, etc.

Automating testing wasn't a good idea at the time (high risk code, so you don't want to pile a refactor on top of a risky change), but I figured out approximately how long the builds would take, so I started setting timers on my phone. Kick off a build, switch tracks, come back when the alarm hit. By doing that I was able to context switch more efficiently to an unrelated project rather than twiddling my thumbs for twenty minutes every time I needed to wait for the build.

Ditto to all you just said: Figuring out how to strike the balance between "filling myself up" learning new things - while becoming an expert at repetitive drone work (cough cough documentation) was the hardest thing I've done. Still working on it.

Previously I had no balance - always was at one extreme or the other.

Not everyone can find the right balance and that is the issue. This is the reason why we need to strike the right balance when forming a team. Having too many "rockstars" can actually sound good on paper alone.

In my experience the people who actually focus on shipping are the real rockstars.

> performing a set of behaviors repeatedly

I suspect there are some wins to be had by thinking on how to automate or otherwise delegate well-understood repeated behaviors, while still collecting the proceeds from them.

This is something that could interest a smart and curious person for some time, and actually benefit from the intellect and curiosity expended on it. The person can also reframe the "repetitious monotonous task" as "learning the best way to execute and then automate the task". But learning with any confidence takes a lot sampling for any statistical significance!

This is the most succinct description of my experience I’ve seen. Thanks!

That 4th point strikes very close to home.

Maybe the problem is that this kind of personality should be working in R&D instead of regular code-for-money types of work.

These are the types of people that belong in research.

Until they get bored writing grant proposals and lose all their funding.

It would probably be optimal to have a business that can sustain itself in the background so a researcher can be self-funded.

boredom is part of the human condition. It has nothing to do with being smart.

Here are two tips:

1. get sleep

2. drink coffee

It's ironic that if you do 2 too much you can't do 1.

Though you can try to substitute #2 for #1. It works... sort of... for a little while.

Boredom is part of living a sedentary life. Not the human condition.

Check and check. Coffee definitely help me with grinding through boring mental tasks.

I would risk number 2 and replace it with exercise (not too early or too late)