Always Be Quitting (jmmv.dev)

Don't be a hero, don't work every day, build redundant systems where you can make an impact but can leave without blowing everything up.

Your value does not disappear when there is redundancy within your company. If it is a valuable skill there will always be a demand for it outside, and now you can also claim that you are also capable of coaching others in that skill. If the skill is not valuable to the outside world and is a niche to your company, I’d say you still want to move on from that skill exactly because it is not transferable to other jobs. What if your company goes bankrupt?

What do you want me to write down to help someone else do that? Read all the things, just in case!

You don't have to make a big effort of it. Paste the question and answers from the emails into a text file. Make it into a FAQ email to share or paste it into a comment block the next time you mess with that code.

Well, that didn't take more than a single line: "please remember to check relevant RFCs and man pages for additional information. This system depends on DNS for round robin load balancing (etc)" :)

The point of the article is that by increasing team productivity to reduce your own tasks, you now have the chance to learn new things and grow into new roles as opposed to being stuck with the same responsibilities.

It sounds counterintuitive but i see strong logic here -- by doing those 10 things you will definitely grow, perhaps into a high-level role.

My response to executives and managers with this attitude is that they ought to care about processes beyond delivering product for the same reason that a restaurant owner ought to care about processes beyond cooking meals.

It might sound good to have your chefs do literally nothing but cook all shift, but they also need time to wash dishes, sharpen tools, organize spice racks, track inventory, maintain work stations, mop floors, etc. Neglect these things long enough, and you increase the likelihood of accidents happening and decrease the quality of the meals produced.

Yeah, I agree, but I think you are also meant to prepare yourself for a new or higher role in the company.

Looking at the list of what you are supposed to be achieving, it looks like the itinerary of what a manager would want from their perfect employee.

prob because i just read about the 1%ers avoiding paying taxes, and a thousand other much-more-horrific things, only to see the top post on HN advocating for workers to make themselves even more dispensable that they/we already are -- and i don't think it was meant as a joke. :-D

i've always done the 'obsolete yourself' routine, and still do/am -- part of it was/is always self-interest (not advancement, but getting freed from having to do stupid shit), but part of it was/is 'just doing the right thing by the company' and thereby hopefully being part of a successful operation which, if you're not doing anything too evil, would allow me to take some pride in it.

but i know that many of my improvements to products/documentation/training/etc. only help offshore myself _and_ all my co-workers, especially those of us in the US and other expensive places (and we don't even get health insurance).

if i was part of some type of co-op, all that would be taken care of.

one can dream!

Highly-paid professions have cookie-cutter skill-sets taught from the same textbooks at professional schools with the same basic curricula. They are valuable because those skills are valued, not because they trap their clients in some kind of infinite treatment plan.

You might be making yourself disposable specifically in the context of your original role which you are basically making redundant by documenting and automating everything - but trust me any sensible business will want to keep a staff member who massively improved their team's productivity (by enabling them to be more independent with less silo'd knowledge) and reduced the business' risk exposure (by making potentially critical knowledge more accessible and reducing single points of failure).

Employees who try to become indesposable by turning themselves into a mega-silo of knowledge that nobody else in the org has might gain some job security in the short term but they lose out on any potential job progression.

Turning yourself into a silo like this is practically blackmailing your employer into keeping you. They might keep you employed because they need to keep their systems online, but they will also not think twice about replacing you as soon as an opportunity is presented. That is making yourself disposable.

Turning yourself into a leader who improves the outcomes of various teams in a business will not only make you indespensable, it's genuinely the best (if not the only realistic) path for an engineer to work their way up into more senior or C-suite positions.

Is this a fascist dog whistle? I keep seeing it and I don't know why anyone would believe these things unless they are fascist,

A smart manager would start finding someone to receive that knowledge and the smart employee would volunteer to learn. Giving raises to the person with the siloed information to incentivize them to work and share information with other employees is a relatively inexpensive cost to the alternative of spending a yearly salary on someone who’s main draw is being a walking notion/confluence page

With all due respect, it's overdramatic and ridiculous to quote Orwell. Comparing a blog post about career advice to totalitarian state propaganda is absurd.

Harsh, I know, sorry, but....look at your comment. It could literally apply to every 'controversial' article ever posted on HN.

So it's not that I think the advice is bad, but rather that most individuals would fall into one of two buckets: either they would already intuitively be applying these ideas appropriately, or else they would be unqualified to actually do so.

The quality of life on teams like that can make slightly lower pays even worth while, so always consider that your current experience isn't necessarily what all horizons look like.

Though sometimes frank conversation can build your team up better.

Once documentation becomes longer than a page or two, most people's brains shut down and go into TL;DR mode.

1) Your documentation might be long-winded and they want a guided tour or executive summary, or at least a 10,000 foot view from which to start

2) Maybe they don't know where to look for what they're looking for; if you've documented a bunch of functions but provided no curated guide for what code exists and where to look based on a use-case, it might never be found

For some reason "I am meeting with X to address it" sounds better than "I am reading Y to address it." Not sure why. Just something I have noticed.

So in my case it is office politics.

Reading documentation/writing documentation is not considered quite as productive work.

It's about firm boundaries. I remember reading a story on r/TalesFromTechSupport where the OP put down his foot about an older lady not googling things before asking him simple tech-related questions. At first she was annoyed, but after learning to Google effectively before coming to him for harder question she learned a valuable skill and later thanked him for setting those boundaries.

But that's about how to push them. Have you asked them if the documents are hard to read? What are their length - are they overly long? Have you done any testing to see if they even open and struggle with the documentation before they call you?

I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say.

I think it's also company culture, and most companies have a "let's meet and present slides" mentality. So as long as there is no meeting, there probably is no need for you to know.

Now I am older and wiser. My advice is don’t document. This is cultural problem that needs to be solved at much higher level. If leadership doesn’t care then nothing will change and you will get labeled as asshole. Just flow with culture and you will be much happier. Or find a new job.

Have a generic link in which they could find most of their answers. When they ask something that's in the docs, reply with a link. When they ask something that's not, add it to the docs, and reply the answer + "that was missing - I've just added it to the docs" to reinforce the fact that this time it was OK to ask and that they helped you improve the docs.

The more someone asks you things that were searchable, the more you delay the answer with the link. If you make it quicker to search than to ask, that'll encourage them to search.

If they still don't change the attitude, let your manager work. If that doesn't bring any other change - it may be time to move to another team/manager.

You need buy-in from your team lead/line manager and a critical number of team members that actually want to make a cultural shift, but for some reason cannot. Your regular team retrospectives are the place to address this and come up with an action plan how to bake it into teams processes.

One of the possible solutions is to block time in the teams calendar for dedicated "learning". That could be regular "developer forums" or "reading clubs" or what ever.

If a document is required to be read before a meeting, schedule 10min in the beginning of the meeting where all collectively read the doc.

If i were in your shoes, I would ask feedback from my colleagues: am I communicating in a way that works for my teammates? Am I too verbose? Does my doc look intimidating? Are they not interested? What would interest them and could I get to the point faster? Maybe talk about your goals? Maybe your teammates or you manager are not bought in to the idea that people should relinquish their criticality. Maybe they like being like a little sovereign on their chunk of infrastructure, and don't like wasting time learning a system that they see as not theirs, in which case there's a goal alignment problem.

I'm saying this assuming that you can expect competent and helpful feedback. It may or may not be the case, it's up to you to assess. However you sound like you're already in blaming mode, and I would encourage you not to be. Maybe you're not communicating in a way that works for them. Maybe they need to be convinced that it's worth their time in the first place. If you determine that your colleagues are a lost cause because they do not have the interest or skill, don't waste your time trying to craft the perfect comms either.

Beyond documentation it also means paying super close attention to design. The best systems I've seen were designed with the utmost clarity of purpose, about what they were and what they weren't. It was clear what the important things were and how we were measuring towards these goals. From there, the design flows naturally and the code didn't need much documentation.

I've also seen piles of hacks that made up for their shoddy, misguided, over-engineered design by abundant documentation, which was necessarily hard to understand because the design sucked. There was just no salvation possible through eloquence. Crystal clear design is something that is a lot easier to communicate and share ownership of.

Tangentially related, if someone asks a question, refer them to the documentation - finding the right docs can be harder than reading them. Teach a man to fish etc.

That is very important. You confuse something that is basic with something that is an accessory. Document how software works is essential, writing beautiful diagrams is not. Diagrams must be drawn, just like a teacher does on a blackboard, but they don't need to be perfect.

If you demand beautiful diagrams you require designers with art skills or spending too much time on diagrams software or learning the diagrams' domain specific language.

Either way, spending too much time drawing something could be very bad idea.

If something is important you should demand it on your team, but it is a good idea that you have documented those reasons too and for people on your team to contribute too. You will be surprised how easy is for people to accept them when there are real reasons behind and it is not about another tyrant imposing his will on them with whimsical arbitrariness of autocracy.

But you need to do work too, you must be open to the possibility that it is you who is mistaken, putting your ego (or someone else's ego) to the side. Usually there is very dominant people on the team that constantly fight for dominance, being them right or not.

1. People do not have the time (or think they do not have the time) to read documentation for more than 5min by default. They need to consciously allocated that time.

2. C-level types generally do not read details IMO, presumably because they think they won't understand it anyways. (thus, "executive summary")

3. Everyone who aspires to become C-level someday copies this behavior and ignores all but the "executive summary".

4. Otoh, C-level types are always in meetings. Thus, aspiring career folks will copy this behavior, too and only ever focus on something if they are in a meeting.

5. This culture of only ever sharing information synchronously is somewhat infectious and will spread throughout the company.

6. The behavior is also self-enforcing. If several people are in a meeting-only mode, you can only get them information by scheduling a meeting yourself. This will, step by step, bring you into meeting-only mode.

7. In the end-game the whole company slows down because information is spread only by the speed of meetings.

Does reading your documents really create value for others, or do you want them to validate and give your "more impact"?

You have to first make people curious about your ideas, or they will simply not care.

1. Remain disciplined & use the docs yourself.

2. Bring your doc on screen in a real-time meeting about the topic & update it with the discussion.

3. Link to the doc in emails instead of replying inline.

That said… I’m researching the balance between wiki-style docs and “generated” docs like javadoc, OpenAPI, etc. I wonder if I’m writing too much in the wiki…

The culture is simply set for other priorities.

It may be that your coworkers are so used to the piss-poor quality of average documentation that they don't bother-- even if yours is high quality. I can't blame them.

Most documentation I've seen is some combination of:

    - Inaccurate
    - Verbose
    - Poorly organized

I'm much more likely to read further if a document leads with:

    - A single-sentence summary
    - A 5(ish) bullet overview
    - Prerequisite knowledge

Incidentally, the Google course[0] or the equivalent is excellent.

[0] https://developers.google.com/tech-writing

Almost everyone understands the value of DRY in code, but not everyone sees the value of it in day to day processes in the same light.

Writing documentation is always difficult. It takes a lot of understanding to be able to write.

Often times I think people find themselves in a situation where they need to understand something - but they aren't doing so to write documentation - they're doing so because they have to.

So, if you envision achieving this understanding as climbing a mountain - then documentation is the extra hill at the top you don't want to cross. By the time you're done understanding, the last thing you really want to do is write documentation.

Additionally, documentation is sometimes thankless work.

Making a ticket for documentation kinda solves both of these. 1) You can write a bunch of bullet points and have it be very messy within a ticket, and then you can use those bullet points within the ticket to make the documentation. 2) A ticket is a way of recognizing that documentation requires time and effort, and in a ticket form you have to make time for it in your sprint.

Is this a red flag? Kinda. If you have to write tickets for documents it might mean your team isn't appreciating effort towards documentation, you might have to write tickets to make people write documentation, and you team isn't making time for documentation.

On the other hand, it's a great way to get major pieces of documentation done if you have huge holes in your documentation. For example, if you have a document you need to write that will take 4+ hours of work, it might be a good idea to put that into a ticket.

If they still push for a meeting after that, schedule it so far into the future that it becomes more painful for them to wait than to put effort into understanding the docs. Make this a pattern.

If that doesn't work, get Machiavellian. Schedule the meetings, but occasionally cancel those meetings (and only those meetings) on short-notice. Don't let meetings give them confidence that they will get an easy explanation by X date - make them price in a lack of reliability. Use the same strategy businesses use - make processes you want people to avoid using, unpleasant to deal with. Maybe make it clear that you see those meetings as uniquely low-priority, so the flakiness is bounded.

They're doing it because it's easy to offload the responsibility onto you. It's easier to have you spoon-feed them than to pull their pants up. So you have to make it difficult, so it becomes easier for them to pull their pants up.

Obviously, only use this strategy with co-workers, never with people above you. And if the docs don't answer the question, be extremely reliable and make it explicit in your response: "this isn't covered in the docs, so answering this is high-priority. The foo works by barring the snee..."

Interview them on parts of the system they know well. Capture what they're saying in a document. Draw diagrams together. Write the doc together, show them how you go through the process.

It will show you value their knowledge, and that writing things down means valuing your own knowledge.

Error messages? Nope. Popup boxes? Nope. Documentation? Nope. Emails? Nope. Jira descriptions and reproduction steps? Nope. Example code? Nope.

One person out of a hundred will bother to read anything. Ninety nine will click through or hurriedly scan, and then steal your time to answer questions answered in the first sentence. Or to make you Google things for them.

Somehow they never are as required as they imagine themselves to be.