23 ms·

Always Be Quitting

691 points by bluedino 5y ago

init0 5y ago
Dang! I am already doing 90% of these things, never realized, am I in the right path?
- hathym 5y ago
  You are in the right path until someone on the internet write the total opposite and its article reaches to top page on HN
mikeytown2 5y ago
After getting acquired and some people laid off and replaced with lower cost workers; I think the only reason I have a job is because of the complexity of the system and that it was built quickly so documentation was lacking. This is a great article don't get me wrong, but if you get acquired people might see you as a cost vs asset.
drunkenmagician 5y ago
Hmmm, I have mixed views on almost all these points, context matters. Much of these views seem to stem from a career working in large orgs, not resource constrained startups 1. Document your knowledge? Well document the right knowledge, endless documents with all the pro's / cons of every choice noted will loose the signal in all the noise. 2. Document your long-term plans? In IT long terms plans means the next 3 - 6 months. Maybe document your thoughts on where something should go, but make it brief. 3. Document your meetings? Well document meetings outcomes / actions and only very important discussion points - no one will care in a couple of weeks 4. Bring others to meetings? Maybe, only if it really adds value (for context or for education) otherwise your burning valuable time 5. Train people around you? Agreed, at appropriate times 6. Identify and train your replacement? Not sure that is all that useful unless you're actually moving on. 7. Give power to the people? If what was meant was enabling broader inclusive decision making - agreed. But otherwise, fully autonomous operating modes need to earn that trust. 8. Do not make yourself the point of contact? Depends, if you're a manager or the decision maker, you need to be the point of contact. 9. Delegate? yes, to a point see 7 10. Always be learning? Yes, of course. But not at the expense of the greater goals (personal / project / company). Nothing worse than an engineer that has not delivered because 'they were learning / wanted to try a new framework.
- bradenb 5y ago
  I feel like all of your points add unnecessary clarity. I don't think anyone would assume you should document the wrong things, or plan what you can't plan, or train people at inappropriate times. The only one I flat out disagree with is your clarification on #6. I do think it is useful to find an "apprentice" or "successor" that can take your role on; this is useful for a few reasons: 1) it allows you to move on (either via promotion or leaving the company) and 2) it gives you a support system (want to take a vacation? now you can!)
- theropost 5y ago
  Where I work there is an entire documentation department, that is almost entirely focused on their templates/standardized documents & proceess, than are are the actual content.
bennysomething 5y ago
If I did everything this article suggests I'd never get any work done.
bhshhshs 5y ago
This is good article though it actually didn’t made any sense in terms of job. There are companies that value good documentation, you will have to write docs to keep your job. And there are companies that don’t care about documentation. By writing documentation, you are wasting your company’s time and money on something that is not important to them. This will not get you promoted but it may get you fired. You want documentation as a priority, then champion it to your leadership. Show them data that documentation saves cost in long run. But writing docs by yourself is not a good strategy for long term success of your career. This brings me to my second point, I agree with author if you replace quitting job with dying. What if a doctor tells you that you have two weeks to live. Will you go do all the things that you always dreamt about or would you be talking with lawyers to get your will and estate in order. Do you have enough life insurance? Are you saving for your family and kids? If you have taken care of your affairs, now if doctor tells you that you got two weeks left, are you going to rush to work and finish your project or just quit? Are you going to spend next 2 weeks with your kids or go on a long hike? Or something else? Do you do any of that right now? Yes I want to live my life as if I am always be dying.
mouzogu 5y ago
Honestly, this blog post is incredibly, incredibly bad advice (well intentioned) but still really bad. The average organisation doesn't operate this way. If you make yourself disposable you are far far more likely to be disposed of then promoted in 9 out of 10 companies. I would even go as far and as cynical to say that if the documentation you create is so good you will just be replaced with by cheaper staff, outsourced or freelancers/contractors. edit: honestly, the worst advice i have ever read on HN in like 10 years. you relationship with your employer is based on leverage, if you make yourself too disposable you are skewing the balance of power against yourself. fwiw i am always a happy to provide basic docs and support to team members but i'm not going to document or automate myself out of a job. i've seen it happen too many times.
- codeafin 5y ago
  I do agree - If there are two employees with the same work output, the one who took the time and effort to pave his way to replacement is going to be let go first.
- thejackgoode 5y ago
  Honest question: do you think that the point of view "your relationship with your employer is based on leverage" creates a plethora of twisted incentives that make life for everyone more miserable (while protecting employment, to an extent)
  - mouzogu 5y ago
    It really does make life miserable in a low key way. Of course it depends a lot on the organisation and the personalities that you work with, particularly management but I would say for every 1 great manager who notices and appreciates your contributions there are 9 who don't. I have a very cynical perspective of workplace dynamics because I've been (and seen others) burnt too many times for taking the initiative or being (in my opinion) too naive in their relationship with management and HR. edit: I think i was a bit too harsh my original comment. I think it is good to make yourself disposable (to yourself) but not to the company. If that makes sense. I have lots of documentation and cmd scripts for basic automation but I avoid sharing them on internal wikis or repos. I only share them with devs on request informally.
gnubet 5y ago
A good philosophy I stopped reading here.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
kanwisher 5y ago
this can be a giant waste of time and energy. Half the time the stuff may not be used later. if you are on an already established project, doing this more will help. sounds like author had someone quit and now he doesn't have the knowledge around the person leaving
- elzbardico 5y ago
  Exactly my feelings when I read this
donw 5y ago
One of the core mindsets that I build within my teams is that everybody is important, but nobody is critical. This drives a lot of our practices. We assume that anybody could leave the team tomorrow, and that we need to onboard their replacement on the quick. Building teams like this isn’t easy, but the outcomes and second-order effects are amazing.
- calvinmorrison 5y ago
  I've lost more coworkers to promotions, transfers and medical emergencies, family problems, mental health breaksz maternity/paternity leave then I ever did to firings and quitting. 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.
rantwasp 5y ago
I guess it’s a good way of thinking. But it’s too idealistic. You see: if you do this it’s true that you might be able to make everyone’s life easier and you may advance your career, but (you knew there was a but) you also lose most of the leverage that comes with specialization and having critical knowledge. Yes, it may be harder to switch what you’re working on inside the current workplace, but it also means that passing you on promotions and rewards can lead to a lot of pain if you decide to look outside. As always, there is a soft spot between being the perfect engineer and 100% disposable because of your impeccable “work ethic” vs just being a nightmare to work with and people not having a choice at all.
- jongleberry 5y ago
  we had a principal engineer who thought he was very skilled and held critical knowledge and tried to use it as leverage. turns out, everyone else considered that poisonous behavior.
  - northern-lights 5y ago
    The real question is - did the company fire him for that? I'd wager a guess that it did not. So, it worked out for him.
    - jongleberry 5y ago
      I don’t know the details as I didn’t work directly with him, but from what I understand he was trying to get a sabbatical to figure out some life stuff, but eventually he had to quit, which was not his desired outcome as he needed the income and didn’t have the time to find another job quickly.
  - MattGaiser 5y ago
    > turns out, everyone else considered that poisonous behavior. But did he get his raise?
  - rantwasp 5y ago
    getting a sabbatical is different from a raise/promotion. one signals that you have other things going on/you don’t care anymore, the other seeks to assert that you are contributing a lot and should be rewarded for this
axaxs 5y ago
Yeah, no. I've literally read hundreds of RFCs, thousands of man pages, and who knows how much else. If I spent time writing down everything I know, I'd never get anything else done. And it's not like I'm some supergenius, all of this info is available freely on the internet. But that doesn't stop folks from asking about DNS, TCP, and other well documented things. Many times domain knowledge is just a person who has the answers somewhat fresh in memory so you don't have to go trudging. But writing those things down each time is both futile and redundant.
- unishark 5y ago
  But it also says .."in a document, bug, code comment—wherever..." 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.
- toast0 5y ago
  Yep, my indespensibleness is that I have all this mostly useness knowledge in my head, and if you show me the problem, I can usually get something useful out of my brain to get somewhere quickly. And if not, I can skim the code and get an idea; and if not, I can sort of operate a debugger. What do you want me to write down to help someone else do that? Read all the things, just in case!
  - puchatek 5y ago
    I think the article is not about general technical knowledge or even knowledge about specific technology used at your company but more about e.g. why a certain way to model your domain makes sense or how an unusual system design will pay off because of future plan X discussed with group of people Y in meeting Z - and here is the architecture diagram for it.
- skybrian 5y ago
  RFC's and man pages are written down already. When they say "write things down" it's not about duplicating that effort, though you might make an FAQ that links to them.
throwawaysleep 5y ago
This seems like a good way to waste a lot of time on something management won’t care about until after they can’t do anything for you. It deeply undermines your leverage if they want to fire you also.
- fungiblecog 5y ago
  This is sad. Do you want to stay with a company that wants to fire you?
  - jamil7 5y ago
    Every company wants to fire you
    - cpach 5y ago
      Uhm, what? How do you mean?
  - throwawaysleep 5y ago
    Until I get a new job and land softly, yes. I want to be the one dictating when I move.
- jongleberry 5y ago
  seems like you need to find a job with better management
  - throwawaysleep 5y ago
    It’s a fundamental problem of misaligned incentives between the employee and employer. It is in the interests of the employee to have a more defensible position, even if it increases employer risk.
    - jongleberry 5y ago
      Which means you need to find a new employer. There are companies and/or managers out there that don’t have these misalign incentives, encourage best practices (like those in this blog post), and provide psychological safety. They exist.
mark_l_watson 5y ago
I agree. Share everything, and be willing to train up more junior people so they can do your job. I have a (good or bad habit, depending on point of view) of not staying long at jobs, but often returning (I have worked for two managers, three different times; and a couple managers two times). I try not to burn bridges, but I enjoy working on new stuff with new people.
iJohnDoe 5y ago
True to the title and not the article, I actually went through this phase recently. I was interviewing for a new job that I was excited about getting. I purposefully never got my hopes up, but towards the end I knew I was going to get the job. I went into 2 weeks notice mode. I started getting stuff done that I put off doing. I finished stuff that were on my list of to-dos for years. I was extremely productive. Felt amazing, and that feeling has continued on and I’ve continued to be more productive than I ever have. I got out of my rut. Force yourself into the mindset that you only have 30 days left to get things done. It may work wonders for your productivity.
- yosito 5y ago
  A couple of months ago I did a similar thing by making a "Before COVID is over" todo list of projects I wanted to complete and goals I wanted to accomplish before some kind of "normal" life came back. I got an insane amount of things done. I'm finishing the last item on that todo list today.
  - Taylor_OD 5y ago
    The first few months of covid for me was getting the massive backlog of things I needed to do done at home. It was fantastic to feel like I actually had a balance in my work and home life for once.
- maininformer 5y ago
  or as the stoics say, what if this was the last time you are doing X? ;)
  - totetsu 5y ago
    What if this the last time I get hiccups..
    - pedroma 5y ago
      Holy shit, I haven't gotten hiccups in years.
okareaman 5y ago
I wonder how many people automated their jobs and then when the pandemic hit and they were sent home management found out they were no longer needed.
- fungiblecog 5y ago
  Basically nobody. People with that level of skill are always wanted
nirui 5y ago
> Paradoxically, by being disposable, you free yourself. You make it easier for yourself to grow into a higher-level role and you make it easier for yourself to change the projects you work on. I think the logical think between "grow into a higher-level role" and "being disposable" is very weak if any? The company will pay big price to promote a highly-valued employee. The task which the employee was working on will be transferred to other member/team in the company, so the promoted employee could work on more important tasks. Some company allows/requires the promoted employee to also monitor the situation to ensure the transaction of task is done correctly during/after the promotion. On the other hand, from a company's stand point, a quitting employee should never be a big concern even if someone intentionally make themselves "indispensable". The points in the article that I agreed with: - "Document your meetings", I always do and call it memo - "Give power to the people" - "Do not make yourself the point of contact", I explain what I was doing in the comments of my code - Not sure why the author put this in, but "Always be learning"
- pooya13 5y ago
  > Not sure why the author put this in, but "Always be learning" 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.
  - unishark 5y ago
    It think it's just based on the title itself. Part of preparing to quit is preparing for what's next.
    - pooya13 5y ago
      Did you read the article? They say at the very top that they don’t mean you should literally keep quitting your jobs, but have a quitting mindset.
- _throwawayaway 5y ago
  > I think the logical think between "grow into a higher-level role" and "being disposable" is very weak if any? It sounds counterintuitive but i see strong logic here -- by doing those 10 things you will definitely grow, perhaps into a high-level role.
passerby1 5y ago
Maybe I'm in the minority or bubble, but I don't know of anyone who has KPIs tied to documenting knowledge in the first place. Business people and product managers rarely care (and why would they!) about anything outside delivering features and fixing bugs. So that's in the KPIs, and KPIs are what sets priorities inside company. Edit: accidentally pressed a submit button.
- YuriNiyazov 5y ago
  Correct. This is why a company that has its shit together will also have engineering managers and engineering leadership generally, in addition to business people and product managers. The engineering leaders, if they are any good, will negotiate and enforce a "you have to give engineers time to rebuild MVPs properly, and to document, etc. etc." policy with business and product.
- bavila 5y ago
  > Business people and product managers rarely care (and why would they!) about anything outside delivering features and fixing bugs. 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.
jongleberry 5y ago
I'd agree on most points, but like others, 1 & 2 I don't agree with. Most of my knowledge is useless or irrelevant, so taking the time to document this knowledge is a waste of time. 90% of writing a document is understanding your audience and "document your knowledge" misses that point. Littering documents and code with various tidbits is also not very helpful and probably not worth anyone's time. Documenting long term plans is also pretty useless. Realistically, anything past 30 days is not going to happen. Documenting your strategy and decision making process may be useful, but your idealistic plans? Probably not unless it's just a few bullet points. The most important documentation is usually the "why?", which ideally should be written before the project starts. Documentation outside of the scope of in-flight projects (which 1 & 2 seem to be encouraging) are not as important as they can be discovered with a tiny bit of effort.
- ngc248 5y ago
  Exactly and document rot is a real thing. No amount of wikis, knowledge bases, notes what have you will never be enough to capture the info updates. We live in an agile world after all. Maintaining documentation/institutional knowledge is a sisyphean task.
booleandilemma 5y ago
Paradoxically, by being disposable, you free yourself. No, you just make yourself disposable. War is peace. Freedom is slavery. Ignorance is strength. Don’t listen to this article. It sounds like something overseers would tell their underlings. And when you’re quitting, that’s the company’s problem, not yours.
- unishark 5y ago
  Is your goal to be indispensable as in the only person still able to maintain some ancient legacy project that is still continuing? Or as in the person who gets things done? 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.
  - hughrr 5y ago
    From detailed experience on this you want to be both the first person to be asked to take on a complex problem and the last person out of the door when things get tough. Make yourself indispensable through being the person running towards danger, being helpful to your colleagues, being knowledgable and treating people with respect but only write stuff down when asked lest someone think you're replaceable by a few confluence pages.
  - pydry 5y ago
    My goal is to be the latter but I've worked with plenty of people who made it a goal to be the former. I don't think it's necessarily irrational. If you're self aware enough to know that you're on the wrong side of the programmer bell curve, you're counting down the days until retirement, if you're living in a market with relatively few tech jobs - this makes sense.
- wyqydsyq 5y ago
  > No, you just make yourself disposable. 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.
yurlungur 5y ago
Not related to the article, but I feel like as active engineers we own it to ourselves to always be preparing for the next play. I recently started doing more interview prep even though I'm not unsatisfied with my position. And I even took a few phone screens just for entertaining the idea and testing the water. Gotta say it just feels nice to be able to go through a couple of those smoothly. I think that actually relieved some latent stress I've been having all this time and made me more at east even at work. Feels good to know that I'm ready when the time comes, even if not now.
- forgotmypw77 5y ago
  I've learned a lot from asking questions at interviews. My approach is to ask as many questions as them.
  - ed_elliott_asc 5y ago
    Out of interest, what do you ask?
    - forgotmypw77 5y ago
      Anything comes to mind i find interesting, especially tech things. I try for knowing their stack and internals and methodology well by the time i,m leaving.
- atulatul 5y ago
  A friend of mine does something like this to test the waters. This approach seems to help prepare to be prepared. But then he sometimes has to face the dilemma- whether to accept the next opportunity. :-)
  - biztos 5y ago
    I can't imagine doing this without actively thinking about leaving my current job for whatever company I'm interviewing with. Which is maybe not a bad idea, say once or twice a year? Even a loyal and supportive manager has certainly run the numbers on life with or without you on the team, and will be told to do so again at some point.
linsomniac 5y ago
Years ago I had an employee who had been with me for over a year and hadn't taken any vacation. I encouraged him to plan a vacation sometime in the coming months, in part, because wend don't really know what things he did at work that weren't fully documented and cross-trained on. Got other people cross trained, things documented, and his vacation went smoothly. A few months later, he got offered a dream job offer, and the transition went smoothly.
asimpletune 5y ago
I feel like the fact that there's a lot of dissent in this thread about whether the advice in the article is good or not means that it may be valuable advice. Like, a lot of advice is great, but also obvious, and, therefore, in a sense, is widely understood and known to be true, hence not quite as valuable as some rare advice out there. The kind of advice out there that people may not quite agree on or even understand. The advice in this article may be the second type, judging by the lack of agreement here within the thread.
- dasil003 5y ago
  In my experience the answer is that it depends heavily on your situation. For every one of these bullets, there is a time and place to do that thing and a time not to. What sets senior folks apart is the judgement of when these things would apply and how to do them effectively. If a junior IC comes in and starts cargo culting off this they could easily spend all their time writing useless docs and sowing confusion and disrupting the team while completely ignoring the core competencies of their job. 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.
- onion2k 5y ago
  It might be great advice that people don't understand, but it might also be terrible advice that people do understand. The opinions of a bunch of strangers who you have no trust in isn't enough to inform you either way, but you should note that ought to include both HN readers posting here and the author of the article.
- readonthegoapp 5y ago
  This sounds like GPT-3 if GPT-3 were a lot worse than it is -- so more like a run-of-the-mill spambot that slipped by Akismet. Harsh, I know, sorry, but....look at your comment. It could literally apply to every 'controversial' article ever posted on HN.
  - asimpletune 5y ago
ffggvv 5y ago
I dont evne document things when i leave. not my problem.
uDontKnowMe 5y ago
What does one do when they live by this philosophy of documenting everything and making sure knowledge is captured, but your team mates just refuse to volley the ball back? I find myself documenting how the software works, writing up proposals with beautiful diagrams etc, but my teammates won't take the simple step to even read the dang thing without scheduling a meeting with me to spoon feed / read it aloud to them.
- koonsolo 5y ago
  My experience too. I guess most people are just not wired to read documentation. 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.
  - Layke1123 5y ago
    Thats not true. Good documentation is INVALUABLE. Deciphering some arcane manuscript that is out of date and can't cover all the nuances of what could go wrong is asking for trouble when teaching people. Teachers exist for a reason. It's because people learn better from people, especially in the middle of a pandemic where we've been forced to be apart.
  - vladvasiliu 5y ago
    > I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say. To build on this, it's more than just being spoon-fed, it's being told exactly what to do, step by step. I think this may have several causes, but one I can see is being afraid to take responsibility. "I've just followed the procedure! It's not my fault if it didn't work / brought the site down!". And this comes down to the local company culture. Presenting a nice documentation, which is more general, although more complete, means that the reader must actually understand what the doc says. Now, of course, they may have been trained by shoddy docs that it's oftentimes an arduous, uphill battle, so they have a knee-jerk reaction to it. But they also have to take responsibility for their actions, which, in a culture of cover-your-ass above all else, is a tough sell.
_throwawayaway 5y ago
Judging by the comments following this advice will get 50% of folks fired and 50% promoted.
- biztos 5y ago
  Is that stack-ranking? /s
northern-lights 5y ago
Perhaps the attitude instead should be: Always Be Interviewing Everybody's replaceable. Capitalist corporations will replace you at the drop of a hat if they can. The only way to safeguard yourself is to be ready for it.
geocrasher 5y ago
I always expressed this as having a plan in place in case I were to get hit by a bus. The world can't come to a halt just because I wake up dead one day. It's very much the same idea, I think.
- cuddlecake 5y ago
  But it's not the world coming to a halt: It's just the next engineer going "uh what the heck is this".
  - geocrasher 5y ago
    Indeed it was hyperbole.
- WJW 5y ago
  As the saying goes: The graveyards are filled with indispensible people. Somehow they never are as required as they imagine themselves to be.
mike00632 5y ago
Similar idea but not related to work: act like you're going to be moving away from town soon. You'll think of all those parks and attractions in your local area that you always said you'd go to but never took the time for.
hathym 5y ago
My comapny reduced the numbers of epmloyees from 1500 to less than 200. As soon as they feel you are replaceable, you are eifher disposed or replaced by a cheaper one overseas.
Brajeshwar 5y ago
A few years back, I had the opportunity to lead the Product Team of a 200+ people company. It took me over a month to understood who does what, and I tend to try to know things around me and at least have the idea of “what to do in an emergency.” I stumble on one DevOps guy who wrote every bloody thing happening in the system. He likes doing it, but from the way people were asking questions in the common chatrooms, group emails, I knew nobody read them. He loves plain text, nicely formatted with the old-school Unix-styles et al. I had talks with him outside of work and found him fascinating; I asked him help with my hobby, home-lab tinkerings, etc. By that time, I had already started internal blog groups and was encouraging people to write. And indeed, a lot of people came out to write about engineering, marketing, product, and it became a routine for people to show off what they can do, what they love, and what they are good at. In one of my regular company-wide emailers, I dedicated a big piece to the DevOps guy, pointing to his work and the beauty of his documentations. People loved it, and they began reading it. He remained a friend. That mailer was the only way I could highlight people I encounter doing good work, to the whole team up to the CxOs. By the time I left the company, I was responsible for many vital things in the company, but I could transition everything smoothly with the documents and credential details (thanks to 1Password). In the last year or so, I have been thinking more about -- always be dying. I think the similar vein of Always be Quitting; I try to document, write out details, just in case I die and my family has to figure out the intricacies.
- gary_0 5y ago
  > just in case I die and my family has to figure out the intricacies I'm reminded of how so much of what we know about history is because of the diaries and correspondence that happened to survive to the present day. There are surprising gaps in what we know about day-to-day life in the distant past because nobody bothered (or was able) to write it down.
  - eru 5y ago
    To be slightly flippant: we get even more valuable information out of garbage dumps. People usually bias their writing towards what they consider to be important information. And they leave out what they consider obvious context. So we have a lot more information about battles and kings, then about daily life. People are less biased towards highfalutin in the ways they produce garbage.
mdr0id 5y ago
You assume that all devs are responsible, they are not. It's a dangerous mindset "always be quitting" for someone who is not responsible. They will do exactly the opposite of what is mentioned in the article.
deleted 5y ago
[deleted]
tdrgabi 5y ago
I see a lot of support in comments for documenting everything. People say they write everything down and their colleagues don't read it. If you document everything I imagine a huge wiki (confluence) full of irrelevant docs for the task that I'm looking to solve right now. Instead of spending an excruciating boring day sifting through it on the chance I find what I'm looking for, offcourse I ask for a quick intro. It reminds me of https://mobile.twitter.com/ismonkeyuser/status/1290583571284086785/photo/1 https://mobile.twitter.com/ismonkeyuser/status/1290583571284...
- tdrgabi 5y ago
  Instead of bugs it's docs.
ecmascript 5y ago
> Document your knowledge. Every time someone asks you a question, they are highlighting a gap in the documentation. Take the chance to write the answer down (in a document, bug, code comment—wherever) so that the next person doesn’t need YOU. This and many more of his advice are very good for companies but suck for the individual. I would say not to follow the authors advice because it will make no one reliant on you. It is also incredible time consuming and will only weaken your position. This article is basically saying not to drive you car so much or else it won't be fresh for the next owner. This is corporate simping.
jerome-jh 5y ago
This made me reflect on a recent experience when I got stuck as a single SW developer maintaining a (more than) mature project. If I had been more friendly and supportive to junior developers and contractors, polished documentation, updated build system, I could probably have left this project much earlier while looking like a better person.
bluedino 5y ago
>> Document your meetings. We had an issue stemming from a convoluted setup where images were being copied to a web server every night, from a document server, something went wrong with the logic in the script and we ended up with missing and out dated images on a web site. I suggested that we just allow the document server to serve the images over http. The response was "We thought about that but decided against it." I then asked why? Who decided that? Nobody knew. Had the meeting been documented, we'd hopefully be able to go back and see 'Dave recommended we not do that because of X and Y...'
phlipski 5y ago
"Document your meetings" - ugh I'm still surprised 20 years into my career at the amount of times people hold a meeting and DON'T TAKE ANY MINUTES!!! I recently asked someone, "Do you not normally take minutes?" His response, "I just generally keep it in my head." I thought, "What about the other 10 people on this call? You (foolishly) assume they have the same photographic recall? I certainly don't!" People - document your meetings! It takes a few minutes. And it will save your ass down the line when some inevitable squabble arises over what people "agreed to work on" but there is no paper trail to settle the argument!
- mcherm 5y ago
  This is my superpower. When I attend meetings I take notes. I'm willing to share those notes with anyone who needs them. I look back at my notes to recall details or find key links and figures. This makes me a significantly better engineer and subject matter expert.
- thrower123 5y ago
  It would be a worthwhile investment to pay an administrative assistant (or, actually, stenographer) solely to sit in on meetings and take notes. One would think that this ought to be automatic these days, since we've got speech-to-text that mostly works, and ubiquitous meeting recording, and yet...
- e12e 5y ago
  Not only no meeting minutes - start with a proper agenda...
______- 5y ago
Worth reading `Linchpin: Are You Indispensable? ' by Seth Godin > Seth Godin describes a Linchpin as somebody in an organization who is indispensable - who simply cannot be replaced because their role is just far too unique and valuable. https://www.forbes.com/sites/mikemyatt/2011/11/29/seth-godins-linchpin-theory-sound-advice-or-career-suicide/ https://www.forbes.com/sites/mikemyatt/2011/11/29/seth-godin...
elzbardico 5y ago
Make your job disposable to you. Not for the company.
fudged71 5y ago
This one is maybe even too obvious for the article, but: share your passwords. Even if you are the only developer on the team, you should not be the only one with access. Also I like to think of this methodology as “what if I got amnesia tomorrow?” You need to get everything out of your head onto a shared knowledgebase.
- bdefore 5y ago
  I agree in spirit but would revise: it's a security threat and against some company policies to explicitly share passwords in the clear. The ideal is to add your password to a corporate password vault, some of which can then authenticate for coworkers without them knowing explicitly what it is.
  - fudged71 5y ago
    Sorry yes, that’s what I meant. A password manager/vault.
mym1990 5y ago
'Every time someone asks you a question, they are highlighting a gap in the documentation.' This would be ideal, but whenever someone asks me a question there is a high probability that they just don't want to take the time to read and process the documentation.
dangus 5y ago
The question I had reading this: when will my company incentivize this behavior? I get no significant equity. I just get paid a salary. As an employee, it’s in my best interest to be indispensable to my company’s operations. If I have made myself replaceable, I have no leverage over salary negotiations. Obviously, the argument I’m making here is taking this concept to an extreme. Nonetheless, I think it’s a good question to be asking: why should I do this if my company doesn’t care either way? The only reason I can think of is that I don’t want to be the point of contact for everything and be bothered off-hours. But in every other respect, I want my company to think “we couldn’t do it without them” every time my name comes up.
teekert 5y ago
So true! I had an experience after which I sort of emotionally divorced from my company (but not the friends I made working there!) and it left me more relaxed, more balsy and with an attitude like “They are lucky they have me, and if they don’t think so? Fine, bye!” I ask less for permission, take ownership more, am less afraid to get fired. And it is very much appreciated! Moreover, the occasional job interview I go to (because why not) taught me a lot and sometimes almost led to new and valuable collaborations.
airhead969 5y ago
This is good advice for founders and people intent on, and capable of, advancement, but it's generally bad advice for everyone else because it makes them easily disposable.
tikiman163 5y ago
It's a good ideology, and I would suggest following it where possible, but I do see certain bad assumptions being made. These are the sort of thing I always try to do, but recently I've wound up on a team with only myself to do all architecture, programming, documentation and story writing. We have 2 QAs a team manager and someone who's in charge of coordinating market activity and sort of doing product management, but despite having multiple projects on my plate, I am the only developer. I can document things just fine, but there is no replacement for me to train. I've honestly been trying to make myself replaceable, but sometimes management just doesn't understand how many people they should have hired and when people leave it can easily result in that becoming impossible. Under those circumstances people either burn out and lose those habits, or they simply find a new job and leave just to get away from the bad situation. I'm getting pretty close to burnout in my own situation and I'm eyeballing an escape plan before somebody else can end up putting even more work on me.
deanCommie 5y ago
This is only good advice for the most senior people or anyone who has unquestionable trust from their management/leadership. Turns out if you're not one of those people, at review time nobody values this behaviour. It's only "what did you deliver". So yes, it's important to train, document, and delegate. It's valuable. You should do it. But if you still have yet to earn trust or a reputation, and you want to actually exceed expectations and be known as the type of performer that gets things done, you have to lean in a little more into delivery and a little less into all the instructions on this page.
runawaybottle 5y ago
One thing I’ll say is that not everyone knows how to write good documentation. There’s a difference between writing a reference index, a getting started guide, design pattern motivation, and so on. They are all very different things.
betwixthewires 5y ago
All great advice. I guess I behave in many of these ways just because of my personality, I've never understood (or liked) people who try to entrench themselves in some position and become irreplaceable, I've never seen how you can think that is a good strategy for yourself, and this article explains some of that.
Chyzwar 5y ago
I am not sure. I never found much value in companies internal confluence pages. Mostly outdated and poorly organized. Long README for project setup is code smell. Things should "just work" with obvious commands. Best code documentation is automated tests. I think the most important documentation should be your issue tracker. User stories should have clear AC, all work should be captured in tickets and organized in Epics/tags. My big problem with agile is that the total amount of work done for a particular feature is not captured very well. This makes it hard to make strategic decisions. You might have multiple teams re-inventing the same wheel or facing similar problems.
mikmeh 5y ago
As a one man shop for the small company I work for this is great advice. Inspired me to create a new "read this in case of emergency" doc if I get hit by a bus.

Always Be Quitting

691 points by bluedino 5y ago

init0 5y ago

Dang! I am already doing 90% of these things, never realized, am I in the right path?

hathym 5y ago
You are in the right path until someone on the internet write the total opposite and its article reaches to top page on HN

mikeytown2 5y ago

After getting acquired and some people laid off and replaced with lower cost workers; I think the only reason I have a job is because of the complexity of the system and that it was built quickly so documentation was lacking. This is a great article don't get me wrong, but if you get acquired people might see you as a cost vs asset.

drunkenmagician 5y ago

Hmmm, I have mixed views on almost all these points, context matters. Much of these views seem to stem from a career working in large orgs, not resource constrained startups 1. Document your knowledge? Well document the right knowledge, endless documents with all the pro's / cons of every choice noted will loose the signal in all the noise. 2. Document your long-term plans? In IT long terms plans means the next 3 - 6 months. Maybe document your thoughts on where something should go, but make it brief. 3. Document your meetings? Well document meetings outcomes / actions and only very important discussion points - no one will care in a couple of weeks 4. Bring others to meetings? Maybe, only if it really adds value (for context or for education) otherwise your burning valuable time 5. Train people around you? Agreed, at appropriate times 6. Identify and train your replacement? Not sure that is all that useful unless you're actually moving on. 7. Give power to the people? If what was meant was enabling broader inclusive decision making - agreed. But otherwise, fully autonomous operating modes need to earn that trust. 8. Do not make yourself the point of contact? Depends, if you're a manager or the decision maker, you need to be the point of contact. 9. Delegate? yes, to a point see 7 10. Always be learning? Yes, of course. But not at the expense of the greater goals (personal / project / company). Nothing worse than an engineer that has not delivered because 'they were learning / wanted to try a new framework.

bradenb 5y ago
I feel like all of your points add unnecessary clarity. I don't think anyone would assume you should document the wrong things, or plan what you can't plan, or train people at inappropriate times. The only one I flat out disagree with is your clarification on #6. I do think it is useful to find an "apprentice" or "successor" that can take your role on; this is useful for a few reasons: 1) it allows you to move on (either via promotion or leaving the company) and 2) it gives you a support system (want to take a vacation? now you can!)
theropost 5y ago
Where I work there is an entire documentation department, that is almost entirely focused on their templates/standardized documents & proceess, than are are the actual content.

bennysomething 5y ago

If I did everything this article suggests I'd never get any work done.

bhshhshs 5y ago

This is good article though it actually didn’t made any sense in terms of job. There are companies that value good documentation, you will have to write docs to keep your job. And there are companies that don’t care about documentation. By writing documentation, you are wasting your company’s time and money on something that is not important to them. This will not get you promoted but it may get you fired. You want documentation as a priority, then champion it to your leadership. Show them data that documentation saves cost in long run. But writing docs by yourself is not a good strategy for long term success of your career. This brings me to my second point, I agree with author if you replace quitting job with dying. What if a doctor tells you that you have two weeks to live. Will you go do all the things that you always dreamt about or would you be talking with lawyers to get your will and estate in order. Do you have enough life insurance? Are you saving for your family and kids? If you have taken care of your affairs, now if doctor tells you that you got two weeks left, are you going to rush to work and finish your project or just quit? Are you going to spend next 2 weeks with your kids or go on a long hike? Or something else? Do you do any of that right now? Yes I want to live my life as if I am always be dying.

mouzogu 5y ago

Honestly, this blog post is incredibly, incredibly bad advice (well intentioned) but still really bad. The average organisation doesn't operate this way. If you make yourself disposable you are far far more likely to be disposed of then promoted in 9 out of 10 companies. I would even go as far and as cynical to say that if the documentation you create is so good you will just be replaced with by cheaper staff, outsourced or freelancers/contractors. edit: honestly, the worst advice i have ever read on HN in like 10 years. you relationship with your employer is based on leverage, if you make yourself too disposable you are skewing the balance of power against yourself. fwiw i am always a happy to provide basic docs and support to team members but i'm not going to document or automate myself out of a job. i've seen it happen too many times.

codeafin 5y ago
I do agree - If there are two employees with the same work output, the one who took the time and effort to pave his way to replacement is going to be let go first.
thejackgoode 5y ago
Honest question: do you think that the point of view "your relationship with your employer is based on leverage" creates a plethora of twisted incentives that make life for everyone more miserable (while protecting employment, to an extent)
- mouzogu 5y ago
  It really does make life miserable in a low key way. Of course it depends a lot on the organisation and the personalities that you work with, particularly management but I would say for every 1 great manager who notices and appreciates your contributions there are 9 who don't. I have a very cynical perspective of workplace dynamics because I've been (and seen others) burnt too many times for taking the initiative or being (in my opinion) too naive in their relationship with management and HR. edit: I think i was a bit too harsh my original comment. I think it is good to make yourself disposable (to yourself) but not to the company. If that makes sense. I have lots of documentation and cmd scripts for basic automation but I avoid sharing them on internal wikis or repos. I only share them with devs on request informally.

gnubet 5y ago

A good philosophy I stopped reading here.

deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

kanwisher 5y ago

this can be a giant waste of time and energy. Half the time the stuff may not be used later. if you are on an already established project, doing this more will help. sounds like author had someone quit and now he doesn't have the knowledge around the person leaving

elzbardico 5y ago
Exactly my feelings when I read this

donw 5y ago

One of the core mindsets that I build within my teams is that everybody is important, but nobody is critical. This drives a lot of our practices. We assume that anybody could leave the team tomorrow, and that we need to onboard their replacement on the quick. Building teams like this isn’t easy, but the outcomes and second-order effects are amazing.

calvinmorrison 5y ago
I've lost more coworkers to promotions, transfers and medical emergencies, family problems, mental health breaksz maternity/paternity leave then I ever did to firings and quitting. 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.

rantwasp 5y ago

I guess it’s a good way of thinking. But it’s too idealistic. You see: if you do this it’s true that you might be able to make everyone’s life easier and you may advance your career, but (you knew there was a but) you also lose most of the leverage that comes with specialization and having critical knowledge. Yes, it may be harder to switch what you’re working on inside the current workplace, but it also means that passing you on promotions and rewards can lead to a lot of pain if you decide to look outside. As always, there is a soft spot between being the perfect engineer and 100% disposable because of your impeccable “work ethic” vs just being a nightmare to work with and people not having a choice at all.

jongleberry 5y ago
we had a principal engineer who thought he was very skilled and held critical knowledge and tried to use it as leverage. turns out, everyone else considered that poisonous behavior.
- northern-lights 5y ago
  The real question is - did the company fire him for that? I'd wager a guess that it did not. So, it worked out for him.
  - jongleberry 5y ago
    I don’t know the details as I didn’t work directly with him, but from what I understand he was trying to get a sabbatical to figure out some life stuff, but eventually he had to quit, which was not his desired outcome as he needed the income and didn’t have the time to find another job quickly.
- MattGaiser 5y ago
  > turns out, everyone else considered that poisonous behavior. But did he get his raise?
- rantwasp 5y ago
  getting a sabbatical is different from a raise/promotion. one signals that you have other things going on/you don’t care anymore, the other seeks to assert that you are contributing a lot and should be rewarded for this

axaxs 5y ago

Yeah, no. I've literally read hundreds of RFCs, thousands of man pages, and who knows how much else. If I spent time writing down everything I know, I'd never get anything else done. And it's not like I'm some supergenius, all of this info is available freely on the internet. But that doesn't stop folks from asking about DNS, TCP, and other well documented things. Many times domain knowledge is just a person who has the answers somewhat fresh in memory so you don't have to go trudging. But writing those things down each time is both futile and redundant.

unishark 5y ago
But it also says .."in a document, bug, code comment—wherever..." 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.
toast0 5y ago
Yep, my indespensibleness is that I have all this mostly useness knowledge in my head, and if you show me the problem, I can usually get something useful out of my brain to get somewhere quickly. And if not, I can skim the code and get an idea; and if not, I can sort of operate a debugger. What do you want me to write down to help someone else do that? Read all the things, just in case!
- puchatek 5y ago
  I think the article is not about general technical knowledge or even knowledge about specific technology used at your company but more about e.g. why a certain way to model your domain makes sense or how an unusual system design will pay off because of future plan X discussed with group of people Y in meeting Z - and here is the architecture diagram for it.
skybrian 5y ago
RFC's and man pages are written down already. When they say "write things down" it's not about duplicating that effort, though you might make an FAQ that links to them.

throwawaysleep 5y ago

This seems like a good way to waste a lot of time on something management won’t care about until after they can’t do anything for you. It deeply undermines your leverage if they want to fire you also.

fungiblecog 5y ago
This is sad. Do you want to stay with a company that wants to fire you?
- jamil7 5y ago
  Every company wants to fire you
  - cpach 5y ago
    Uhm, what? How do you mean?
- throwawaysleep 5y ago
  Until I get a new job and land softly, yes. I want to be the one dictating when I move.
jongleberry 5y ago
seems like you need to find a job with better management
- throwawaysleep 5y ago
  It’s a fundamental problem of misaligned incentives between the employee and employer. It is in the interests of the employee to have a more defensible position, even if it increases employer risk.
  - jongleberry 5y ago
    Which means you need to find a new employer. There are companies and/or managers out there that don’t have these misalign incentives, encourage best practices (like those in this blog post), and provide psychological safety. They exist.

mark_l_watson 5y ago

I agree. Share everything, and be willing to train up more junior people so they can do your job. I have a (good or bad habit, depending on point of view) of not staying long at jobs, but often returning (I have worked for two managers, three different times; and a couple managers two times). I try not to burn bridges, but I enjoy working on new stuff with new people.

iJohnDoe 5y ago

True to the title and not the article, I actually went through this phase recently. I was interviewing for a new job that I was excited about getting. I purposefully never got my hopes up, but towards the end I knew I was going to get the job. I went into 2 weeks notice mode. I started getting stuff done that I put off doing. I finished stuff that were on my list of to-dos for years. I was extremely productive. Felt amazing, and that feeling has continued on and I’ve continued to be more productive than I ever have. I got out of my rut. Force yourself into the mindset that you only have 30 days left to get things done. It may work wonders for your productivity.

yosito 5y ago
A couple of months ago I did a similar thing by making a "Before COVID is over" todo list of projects I wanted to complete and goals I wanted to accomplish before some kind of "normal" life came back. I got an insane amount of things done. I'm finishing the last item on that todo list today.
- Taylor_OD 5y ago
  The first few months of covid for me was getting the massive backlog of things I needed to do done at home. It was fantastic to feel like I actually had a balance in my work and home life for once.
maininformer 5y ago
or as the stoics say, what if this was the last time you are doing X? ;)
- totetsu 5y ago
  What if this the last time I get hiccups..
  - pedroma 5y ago
    Holy shit, I haven't gotten hiccups in years.

okareaman 5y ago

I wonder how many people automated their jobs and then when the pandemic hit and they were sent home management found out they were no longer needed.

fungiblecog 5y ago
Basically nobody. People with that level of skill are always wanted

nirui 5y ago

> Paradoxically, by being disposable, you free yourself. You make it easier for yourself to grow into a higher-level role and you make it easier for yourself to change the projects you work on. I think the logical think between "grow into a higher-level role" and "being disposable" is very weak if any? The company will pay big price to promote a highly-valued employee. The task which the employee was working on will be transferred to other member/team in the company, so the promoted employee could work on more important tasks. Some company allows/requires the promoted employee to also monitor the situation to ensure the transaction of task is done correctly during/after the promotion. On the other hand, from a company's stand point, a quitting employee should never be a big concern even if someone intentionally make themselves "indispensable". The points in the article that I agreed with: - "Document your meetings", I always do and call it memo - "Give power to the people" - "Do not make yourself the point of contact", I explain what I was doing in the comments of my code - Not sure why the author put this in, but "Always be learning"

pooya13 5y ago
> Not sure why the author put this in, but "Always be learning" 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.
- unishark 5y ago
  It think it's just based on the title itself. Part of preparing to quit is preparing for what's next.
  - pooya13 5y ago
    Did you read the article? They say at the very top that they don’t mean you should literally keep quitting your jobs, but have a quitting mindset.
_throwawayaway 5y ago
> I think the logical think between "grow into a higher-level role" and "being disposable" is very weak if any? It sounds counterintuitive but i see strong logic here -- by doing those 10 things you will definitely grow, perhaps into a high-level role.

passerby1 5y ago

Maybe I'm in the minority or bubble, but I don't know of anyone who has KPIs tied to documenting knowledge in the first place. Business people and product managers rarely care (and why would they!) about anything outside delivering features and fixing bugs. So that's in the KPIs, and KPIs are what sets priorities inside company. Edit: accidentally pressed a submit button.

YuriNiyazov 5y ago
Correct. This is why a company that has its shit together will also have engineering managers and engineering leadership generally, in addition to business people and product managers. The engineering leaders, if they are any good, will negotiate and enforce a "you have to give engineers time to rebuild MVPs properly, and to document, etc. etc." policy with business and product.
bavila 5y ago
> Business people and product managers rarely care (and why would they!) about anything outside delivering features and fixing bugs. 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.

jongleberry 5y ago

I'd agree on most points, but like others, 1 & 2 I don't agree with. Most of my knowledge is useless or irrelevant, so taking the time to document this knowledge is a waste of time. 90% of writing a document is understanding your audience and "document your knowledge" misses that point. Littering documents and code with various tidbits is also not very helpful and probably not worth anyone's time. Documenting long term plans is also pretty useless. Realistically, anything past 30 days is not going to happen. Documenting your strategy and decision making process may be useful, but your idealistic plans? Probably not unless it's just a few bullet points. The most important documentation is usually the "why?", which ideally should be written before the project starts. Documentation outside of the scope of in-flight projects (which 1 & 2 seem to be encouraging) are not as important as they can be discovered with a tiny bit of effort.

ngc248 5y ago
Exactly and document rot is a real thing. No amount of wikis, knowledge bases, notes what have you will never be enough to capture the info updates. We live in an agile world after all. Maintaining documentation/institutional knowledge is a sisyphean task.

booleandilemma 5y ago

Paradoxically, by being disposable, you free yourself. No, you just make yourself disposable. War is peace. Freedom is slavery. Ignorance is strength. Don’t listen to this article. It sounds like something overseers would tell their underlings. And when you’re quitting, that’s the company’s problem, not yours.

unishark 5y ago
Is your goal to be indispensable as in the only person still able to maintain some ancient legacy project that is still continuing? Or as in the person who gets things done? 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.
- hughrr 5y ago
  From detailed experience on this you want to be both the first person to be asked to take on a complex problem and the last person out of the door when things get tough. Make yourself indispensable through being the person running towards danger, being helpful to your colleagues, being knowledgable and treating people with respect but only write stuff down when asked lest someone think you're replaceable by a few confluence pages.
- pydry 5y ago
  My goal is to be the latter but I've worked with plenty of people who made it a goal to be the former. I don't think it's necessarily irrational. If you're self aware enough to know that you're on the wrong side of the programmer bell curve, you're counting down the days until retirement, if you're living in a market with relatively few tech jobs - this makes sense.
wyqydsyq 5y ago
> No, you just make yourself disposable. 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.

yurlungur 5y ago

Not related to the article, but I feel like as active engineers we own it to ourselves to always be preparing for the next play. I recently started doing more interview prep even though I'm not unsatisfied with my position. And I even took a few phone screens just for entertaining the idea and testing the water. Gotta say it just feels nice to be able to go through a couple of those smoothly. I think that actually relieved some latent stress I've been having all this time and made me more at east even at work. Feels good to know that I'm ready when the time comes, even if not now.

forgotmypw77 5y ago
I've learned a lot from asking questions at interviews. My approach is to ask as many questions as them.
- ed_elliott_asc 5y ago
  Out of interest, what do you ask?
  - forgotmypw77 5y ago
    Anything comes to mind i find interesting, especially tech things. I try for knowing their stack and internals and methodology well by the time i,m leaving.
atulatul 5y ago
A friend of mine does something like this to test the waters. This approach seems to help prepare to be prepared. But then he sometimes has to face the dilemma- whether to accept the next opportunity. :-)
- biztos 5y ago
  I can't imagine doing this without actively thinking about leaving my current job for whatever company I'm interviewing with. Which is maybe not a bad idea, say once or twice a year? Even a loyal and supportive manager has certainly run the numbers on life with or without you on the team, and will be told to do so again at some point.

linsomniac 5y ago

Years ago I had an employee who had been with me for over a year and hadn't taken any vacation. I encouraged him to plan a vacation sometime in the coming months, in part, because wend don't really know what things he did at work that weren't fully documented and cross-trained on. Got other people cross trained, things documented, and his vacation went smoothly. A few months later, he got offered a dream job offer, and the transition went smoothly.

asimpletune 5y ago

I feel like the fact that there's a lot of dissent in this thread about whether the advice in the article is good or not means that it may be valuable advice. Like, a lot of advice is great, but also obvious, and, therefore, in a sense, is widely understood and known to be true, hence not quite as valuable as some rare advice out there. The kind of advice out there that people may not quite agree on or even understand. The advice in this article may be the second type, judging by the lack of agreement here within the thread.

dasil003 5y ago
In my experience the answer is that it depends heavily on your situation. For every one of these bullets, there is a time and place to do that thing and a time not to. What sets senior folks apart is the judgement of when these things would apply and how to do them effectively. If a junior IC comes in and starts cargo culting off this they could easily spend all their time writing useless docs and sowing confusion and disrupting the team while completely ignoring the core competencies of their job. 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.
onion2k 5y ago
It might be great advice that people don't understand, but it might also be terrible advice that people do understand. The opinions of a bunch of strangers who you have no trust in isn't enough to inform you either way, but you should note that ought to include both HN readers posting here and the author of the article.
readonthegoapp 5y ago
This sounds like GPT-3 if GPT-3 were a lot worse than it is -- so more like a run-of-the-mill spambot that slipped by Akismet. Harsh, I know, sorry, but....look at your comment. It could literally apply to every 'controversial' article ever posted on HN.
- asimpletune 5y ago

ffggvv 5y ago

I dont evne document things when i leave. not my problem.

uDontKnowMe 5y ago

What does one do when they live by this philosophy of documenting everything and making sure knowledge is captured, but your team mates just refuse to volley the ball back? I find myself documenting how the software works, writing up proposals with beautiful diagrams etc, but my teammates won't take the simple step to even read the dang thing without scheduling a meeting with me to spoon feed / read it aloud to them.

koonsolo 5y ago
My experience too. I guess most people are just not wired to read documentation. 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.
- Layke1123 5y ago
  Thats not true. Good documentation is INVALUABLE. Deciphering some arcane manuscript that is out of date and can't cover all the nuances of what could go wrong is asking for trouble when teaching people. Teachers exist for a reason. It's because people learn better from people, especially in the middle of a pandemic where we've been forced to be apart.
- vladvasiliu 5y ago
  > I love learning by reading, but most people just want to sit in a classroom and be spoonfed like you say. To build on this, it's more than just being spoon-fed, it's being told exactly what to do, step by step. I think this may have several causes, but one I can see is being afraid to take responsibility. "I've just followed the procedure! It's not my fault if it didn't work / brought the site down!". And this comes down to the local company culture. Presenting a nice documentation, which is more general, although more complete, means that the reader must actually understand what the doc says. Now, of course, they may have been trained by shoddy docs that it's oftentimes an arduous, uphill battle, so they have a knee-jerk reaction to it. But they also have to take responsibility for their actions, which, in a culture of cover-your-ass above all else, is a tough sell.

_throwawayaway 5y ago

Judging by the comments following this advice will get 50% of folks fired and 50% promoted.

biztos 5y ago
Is that stack-ranking? /s

northern-lights 5y ago

Perhaps the attitude instead should be: Always Be Interviewing Everybody's replaceable. Capitalist corporations will replace you at the drop of a hat if they can. The only way to safeguard yourself is to be ready for it.

geocrasher 5y ago

I always expressed this as having a plan in place in case I were to get hit by a bus. The world can't come to a halt just because I wake up dead one day. It's very much the same idea, I think.

cuddlecake 5y ago
But it's not the world coming to a halt: It's just the next engineer going "uh what the heck is this".
- geocrasher 5y ago
  Indeed it was hyperbole.
WJW 5y ago
As the saying goes: The graveyards are filled with indispensible people. Somehow they never are as required as they imagine themselves to be.

mike00632 5y ago

Similar idea but not related to work: act like you're going to be moving away from town soon. You'll think of all those parks and attractions in your local area that you always said you'd go to but never took the time for.

hathym 5y ago

My comapny reduced the numbers of epmloyees from 1500 to less than 200. As soon as they feel you are replaceable, you are eifher disposed or replaced by a cheaper one overseas.

Brajeshwar 5y ago

A few years back, I had the opportunity to lead the Product Team of a 200+ people company. It took me over a month to understood who does what, and I tend to try to know things around me and at least have the idea of “what to do in an emergency.” I stumble on one DevOps guy who wrote every bloody thing happening in the system. He likes doing it, but from the way people were asking questions in the common chatrooms, group emails, I knew nobody read them. He loves plain text, nicely formatted with the old-school Unix-styles et al. I had talks with him outside of work and found him fascinating; I asked him help with my hobby, home-lab tinkerings, etc. By that time, I had already started internal blog groups and was encouraging people to write. And indeed, a lot of people came out to write about engineering, marketing, product, and it became a routine for people to show off what they can do, what they love, and what they are good at. In one of my regular company-wide emailers, I dedicated a big piece to the DevOps guy, pointing to his work and the beauty of his documentations. People loved it, and they began reading it. He remained a friend. That mailer was the only way I could highlight people I encounter doing good work, to the whole team up to the CxOs. By the time I left the company, I was responsible for many vital things in the company, but I could transition everything smoothly with the documents and credential details (thanks to 1Password). In the last year or so, I have been thinking more about -- always be dying. I think the similar vein of Always be Quitting; I try to document, write out details, just in case I die and my family has to figure out the intricacies.

gary_0 5y ago
> just in case I die and my family has to figure out the intricacies I'm reminded of how so much of what we know about history is because of the diaries and correspondence that happened to survive to the present day. There are surprising gaps in what we know about day-to-day life in the distant past because nobody bothered (or was able) to write it down.
- eru 5y ago
  To be slightly flippant: we get even more valuable information out of garbage dumps. People usually bias their writing towards what they consider to be important information. And they leave out what they consider obvious context. So we have a lot more information about battles and kings, then about daily life. People are less biased towards highfalutin in the ways they produce garbage.

mdr0id 5y ago

You assume that all devs are responsible, they are not. It's a dangerous mindset "always be quitting" for someone who is not responsible. They will do exactly the opposite of what is mentioned in the article.

deleted 5y ago

[deleted]

tdrgabi 5y ago

I see a lot of support in comments for documenting everything. People say they write everything down and their colleagues don't read it. If you document everything I imagine a huge wiki (confluence) full of irrelevant docs for the task that I'm looking to solve right now. Instead of spending an excruciating boring day sifting through it on the chance I find what I'm looking for, offcourse I ask for a quick intro. It reminds me of https://mobile.twitter.com/ismonkeyuser/status/1290583571284086785/photo/1 https://mobile.twitter.com/ismonkeyuser/status/1290583571284...

tdrgabi 5y ago
Instead of bugs it's docs.

ecmascript 5y ago

> Document your knowledge. Every time someone asks you a question, they are highlighting a gap in the documentation. Take the chance to write the answer down (in a document, bug, code comment—wherever) so that the next person doesn’t need YOU. This and many more of his advice are very good for companies but suck for the individual. I would say not to follow the authors advice because it will make no one reliant on you. It is also incredible time consuming and will only weaken your position. This article is basically saying not to drive you car so much or else it won't be fresh for the next owner. This is corporate simping.

jerome-jh 5y ago

This made me reflect on a recent experience when I got stuck as a single SW developer maintaining a (more than) mature project. If I had been more friendly and supportive to junior developers and contractors, polished documentation, updated build system, I could probably have left this project much earlier while looking like a better person.

bluedino 5y ago

>> Document your meetings. We had an issue stemming from a convoluted setup where images were being copied to a web server every night, from a document server, something went wrong with the logic in the script and we ended up with missing and out dated images on a web site. I suggested that we just allow the document server to serve the images over http. The response was "We thought about that but decided against it." I then asked why? Who decided that? Nobody knew. Had the meeting been documented, we'd hopefully be able to go back and see 'Dave recommended we not do that because of X and Y...'

phlipski 5y ago

"Document your meetings" - ugh I'm still surprised 20 years into my career at the amount of times people hold a meeting and DON'T TAKE ANY MINUTES!!! I recently asked someone, "Do you not normally take minutes?" His response, "I just generally keep it in my head." I thought, "What about the other 10 people on this call? You (foolishly) assume they have the same photographic recall? I certainly don't!" People - document your meetings! It takes a few minutes. And it will save your ass down the line when some inevitable squabble arises over what people "agreed to work on" but there is no paper trail to settle the argument!

mcherm 5y ago
This is my superpower. When I attend meetings I take notes. I'm willing to share those notes with anyone who needs them. I look back at my notes to recall details or find key links and figures. This makes me a significantly better engineer and subject matter expert.
thrower123 5y ago
It would be a worthwhile investment to pay an administrative assistant (or, actually, stenographer) solely to sit in on meetings and take notes. One would think that this ought to be automatic these days, since we've got speech-to-text that mostly works, and ubiquitous meeting recording, and yet...
e12e 5y ago
Not only no meeting minutes - start with a proper agenda...

______- 5y ago

Worth reading `Linchpin: Are You Indispensable? ' by Seth Godin > Seth Godin describes a Linchpin as somebody in an organization who is indispensable - who simply cannot be replaced because their role is just far too unique and valuable. https://www.forbes.com/sites/mikemyatt/2011/11/29/seth-godins-linchpin-theory-sound-advice-or-career-suicide/ https://www.forbes.com/sites/mikemyatt/2011/11/29/seth-godin...

elzbardico 5y ago

Make your job disposable to you. Not for the company.

fudged71 5y ago

This one is maybe even too obvious for the article, but: share your passwords. Even if you are the only developer on the team, you should not be the only one with access. Also I like to think of this methodology as “what if I got amnesia tomorrow?” You need to get everything out of your head onto a shared knowledgebase.

bdefore 5y ago
I agree in spirit but would revise: it's a security threat and against some company policies to explicitly share passwords in the clear. The ideal is to add your password to a corporate password vault, some of which can then authenticate for coworkers without them knowing explicitly what it is.
- fudged71 5y ago
  Sorry yes, that’s what I meant. A password manager/vault.

mym1990 5y ago

'Every time someone asks you a question, they are highlighting a gap in the documentation.' This would be ideal, but whenever someone asks me a question there is a high probability that they just don't want to take the time to read and process the documentation.

dangus 5y ago

The question I had reading this: when will my company incentivize this behavior? I get no significant equity. I just get paid a salary. As an employee, it’s in my best interest to be indispensable to my company’s operations. If I have made myself replaceable, I have no leverage over salary negotiations. Obviously, the argument I’m making here is taking this concept to an extreme. Nonetheless, I think it’s a good question to be asking: why should I do this if my company doesn’t care either way? The only reason I can think of is that I don’t want to be the point of contact for everything and be bothered off-hours. But in every other respect, I want my company to think “we couldn’t do it without them” every time my name comes up.

teekert 5y ago

So true! I had an experience after which I sort of emotionally divorced from my company (but not the friends I made working there!) and it left me more relaxed, more balsy and with an attitude like “They are lucky they have me, and if they don’t think so? Fine, bye!” I ask less for permission, take ownership more, am less afraid to get fired. And it is very much appreciated! Moreover, the occasional job interview I go to (because why not) taught me a lot and sometimes almost led to new and valuable collaborations.

airhead969 5y ago

This is good advice for founders and people intent on, and capable of, advancement, but it's generally bad advice for everyone else because it makes them easily disposable.

tikiman163 5y ago

It's a good ideology, and I would suggest following it where possible, but I do see certain bad assumptions being made. These are the sort of thing I always try to do, but recently I've wound up on a team with only myself to do all architecture, programming, documentation and story writing. We have 2 QAs a team manager and someone who's in charge of coordinating market activity and sort of doing product management, but despite having multiple projects on my plate, I am the only developer. I can document things just fine, but there is no replacement for me to train. I've honestly been trying to make myself replaceable, but sometimes management just doesn't understand how many people they should have hired and when people leave it can easily result in that becoming impossible. Under those circumstances people either burn out and lose those habits, or they simply find a new job and leave just to get away from the bad situation. I'm getting pretty close to burnout in my own situation and I'm eyeballing an escape plan before somebody else can end up putting even more work on me.

deanCommie 5y ago

This is only good advice for the most senior people or anyone who has unquestionable trust from their management/leadership. Turns out if you're not one of those people, at review time nobody values this behaviour. It's only "what did you deliver". So yes, it's important to train, document, and delegate. It's valuable. You should do it. But if you still have yet to earn trust or a reputation, and you want to actually exceed expectations and be known as the type of performer that gets things done, you have to lean in a little more into delivery and a little less into all the instructions on this page.

runawaybottle 5y ago

One thing I’ll say is that not everyone knows how to write good documentation. There’s a difference between writing a reference index, a getting started guide, design pattern motivation, and so on. They are all very different things.

betwixthewires 5y ago

All great advice. I guess I behave in many of these ways just because of my personality, I've never understood (or liked) people who try to entrench themselves in some position and become irreplaceable, I've never seen how you can think that is a good strategy for yourself, and this article explains some of that.

Chyzwar 5y ago

I am not sure. I never found much value in companies internal confluence pages. Mostly outdated and poorly organized. Long README for project setup is code smell. Things should "just work" with obvious commands. Best code documentation is automated tests. I think the most important documentation should be your issue tracker. User stories should have clear AC, all work should be captured in tickets and organized in Epics/tags. My big problem with agile is that the total amount of work done for a particular feature is not captured very well. This makes it hard to make strategic decisions. You might have multiple teams re-inventing the same wheel or facing similar problems.

mikmeh 5y ago

As a one man shop for the small company I work for this is great advice. Inspired me to create a new "read this in case of emergency" doc if I get hit by a bus.