[HN Gopher] I keep a WTF notebook (2021)
___________________________________________________________________
I keep a WTF notebook (2021)
Author : fanf2
Score : 347 points
Date : 2024-04-18 16:42 UTC (6 hours ago)
(HTM) web link (www.simplermachines.com)
(TXT) w3m dump (www.simplermachines.com)
| mckn1ght wrote:
| It's a good idea because not only do you keep a list of things
| you want to fix, but letting things hang out in there sometimes
| gives you time to understand why something is the way it is.
|
| There will be plenty of times where things were rushed or
| mistakes were made, but sometimes it really is the case that you
| just can't wrap your head around some piece of complexity right
| away just by looking at a line of code.
| theideaofcoffee wrote:
| With enough experience one usually can start to differentiate
| the actual hoo-why-oh-why WTFs from the oh-there's-subtle-
| complexity-here WTFs. The first are straight up failures, the
| second usually resolve themselves after steeping oneself in the
| environment. Still handy to note them down, regardless.
| ergonaught wrote:
| That is roughly how I've approached things whenever I'm walking
| into a pre-existing situation. I spend the first week just
| reviewing everything and writing down questions/observations,
| etc. Not only the "WTF" moments, though. I also take note of
| things that I think work really well or were really great ideas.
|
| Then there's some time to review/prioritize/etc before any sort
| of discussions.
| xandrius wrote:
| I love the concept, I had started some time ago something like
| this but more about things that I wanted fixed/investigated which
| were creating issues for someone/anyone in the team, so whenever
| I have some spare moment I can investigate that further.
|
| Now I have a fun name for it :D
| arduanika wrote:
| Totally agreed. I've always liked this concept, and TIL there's
| a good name!
|
| Also, now I know there's a link! Sometimes you have a new hire
| or team member who's a little too eager to criticize and fix
| everything they see, and you need to sit them down and explain
| this strategy. Now thanks to Bennett, you can back it up with a
| link.
|
| I'd caveat that while a "two week" waiting period might work
| well for Bennett as a senior engineer moving between similar-
| enough teams, a brand new hire or a junior dev might do better
| with a longer delay.
| marginalia_nu wrote:
| I live by just writing down every idea I have in a list. No
| particular order, I just append them on a piece of paper or a
| text file.
|
| Ideas rarely appear when you need them, but come throughout the
| day as you do other things, and at least in my case, I can never
| remember if I don't jot them down.
|
| Then when it's time to get something done, I just cross things
| off one by one. Never have to wonder what to do next, never run
| out of ideas, which allows some pretty spectacular bursts of
| productivity.
| ravenstine wrote:
| This is essentially my note-taking strategy with Apple Notes
| and Notally (on Android). Life's too short to organize notes.
| I'd rather just jot down everything and rely on the reverse-
| chron and search to find stuff later.
|
| The irony is that, while I know I have a treasure trove of
| amazing ideas, at my age I don't think I care enough to execute
| them like I would have in my 20s. Oh well!
| zer00eyz wrote:
| > I don't think I care enough to execute them
|
| You can own this, its totally reasonable to have a good idea
| and say "meh".
|
| > at my age
|
| This is a cop out. It's weak at best and you contributing to
| your own discrimination at worst.
|
| You might not like that but I'm not just talking, I'll bring
| the receipts;
|
| https://medium.com/illumination/late-success-is-
| possible-8ba...
|
| I highly recommend you look at the 77th infantry division in
| WWII: https://www.youtube.com/watch?v=0Su5-_KuDf8 Is an
| entertaining summary.
| ravenstine wrote:
| > This is a cop out.
|
| I see what you are saying, though I find it a bit unfair. I
| don't think age has to stop anyone, and I was more so using
| it as a proxy for being a different person with new
| priorities. In my years approaching 40, I can't say I care
| at all about sitting in front of a screen for hours on end
| making some doo-dad when I could be forming relationships
| that I missed out on earlier in life.
|
| I will definiteky check our your video, though.
| zer00eyz wrote:
| >> I see what you are saying, though I find it a bit
| unfair.
|
| It totally was, and on purpose!!!
|
| >> In my years approaching 40,
|
| At 48 I can tell you that slowing down is NOT what you
| want to do, speed up!
|
| >> I can't say I care at all about sitting in front of a
| screen for hours on end making some doo-dad when I could
| be forming relationships that I missed out on earlier in
| life.
|
| One does not preclude the other. Hell everything is
| better with friends! The thing about old people is we
| dont want doo dads we want to get shit done. You can
| build all the things you want as beer money projects with
| the friends you make and if one of them hits, well... Im
| sure you know better what to do with money now then in
| your 20's.
|
| "Beware of an old man in a profession where men die
| young"
| arduanika wrote:
| I'm struggling to see how this relates to TFA. It sounds like
| you're talking about organizing your personal TODOs, whereas
| the article is about how to acclimate and communicate within a
| team.
| okamiueru wrote:
| I do something similar, except at one shop where the WTFs
| outnumbered everything sane by a wide margin.
| slimsag wrote:
| I think the concept of a 'WTF notebook' is great, and I think
| writing down one's thoughts in general is a good idea. I also
| think that it helps formulate thoughts and communicate them in a
| more thoughtful not-in-the-heat-of-the-moment way.
|
| However,
|
| > For two weeks, that's all I do. I just write it down. I don't
| tell the team everything that I think they're doing wrong. I
| don't show up at retro with all the stuff I think they need to
| change. I just watch, and listen, and I write down everything
| that seems deeply weird.
|
| > [...]
|
| > Before I started keeping this kind of list, I brought up
| problem I saw immediately, as soon as I noticed it. The
| reputation I got was, "Nat's always complaining about things. Nat
| thinks we're never doing things right." People stopped listening
| to me. I was personally frustrated, and professionally
| ineffective.
|
| Not bringing up things that you think could be improved in a
| retro.. that's pretty silly. If you are getting a reputation of
| 'always complaining', and coming across as 'telling people they
| are doing things wrong', etc. then you are just
| bad/unprofessional at communication.
|
| Communicate things as 'I was thinking maybe we could do <X>
| better if <Y>, what do you think?' and make it a genuine
| discussion with people, rather than 'WTF <x>?' - especially when
| it is someone else's work and you want to remain on good terms
| with them.
|
| You don't have to wait 2 weeks, compile a secret list and then
| bring it to your manager - though. You can communicate things
| that you think can be improved in a polite/respectful manner as
| they occur. Being on a team is about working together. If you
| cannot safely do that when communicating effectively, then you
| are with a terrible team/company.
| lrvick wrote:
| If the author is anything like me, I get it.
|
| I have 20 years of software engineering and infosec experience
| can fill a few hours talking about all the crazy risks I find
| in a day of looking around most any company I interact with.
|
| The status quo for security in our industry is abysmally bad.
| Not washing hands while working in a hospital WTF bad,
| everywhere.
|
| Bringing it all up as I go can burn everyone out on interacting
| with me or trusting me at all if I am not careful, because
| survivors bias is a hell of a drug.
|
| Two weeks to collect information and context is about right. I
| just usually do it as a contract security auditor now and
| provide a detailed report at the end.
| al_borland wrote:
| I think you missed the point. This is about someone entering
| into a new team. Walking into a team day 1, knowing nothing,
| and telling everyone they're doing it wrong, is a horrible way
| to start things off.
|
| By watching and waiting a bit, it gives time to learn why the
| stupid things are stupid, what is actually being worked on,
| etc. This helps build trust in the team, because it shows the
| new person respects the team enough to take some time to learn
| how things are before trying to change it. I don't trust anyone
| in a leadership role that starts changing things before taking
| the time to learn how and why things are currently done the way
| they are.
|
| A guy on my team now takes your approach. He derails every
| meeting with the way things "should" be, and he is just saying
| what everyone already knows, he just lacks the understanding on
| why the problem is more difficult to fix than he realizes. If
| he would talk less and listen more, he might understand those
| things better and stop wasting everyone's time.
| blaise-pabon wrote:
| Yes, I think I have been "that guy" when I walk into a
| situation I have been hired to fix, I want to get started
| right away.
|
| If I see a common problem, I want to fix it immediately and
| say something like "I see big batch sizes all the time and
| they have a simple, counter intuitive fix. In fact, of you
| had read more than 30 minutes, you would see it addressed."
| yjftsjthsd-h wrote:
| Waiting a couple weeks makes sure you have enough context to
| usefully contribute with less stepping on toes.
| sonicanatidae wrote:
| I call mine a ticketing system. ;)
| zer00eyz wrote:
| I dont think this article stresses one point enough.
|
| You only get to be "new" once, You only get to have a fresh
| perspective once. There is a reason that you're a bad judge of
| the "usablity" of your product. You already know how to use it.
| your numb to it's mistakes and flaws. New team members dont
| suffer from this!
|
| The bigger lesson here is for the team, and its sadly between the
| lines! You can get a lot of insight based on what new people ask
| about, where they stumble and what they need real help with.
| reaperducer wrote:
| _There is a reason that you 're a bad judge of the "usablity"
| of your product. You already know how to use it. your numb to
| it's mistakes and flaws. New team members dont suffer from
| this!_
|
| One of the best things my company does is allow me to sit down
| on a chair next to the people who use my products as they use
| them.
|
| I just sit there with a notebook and write things down, and
| talk to the users as they're using the product.
|
| Once you start doing that, you understand that it doesn't
| matter how many terabytes of "telemetry" you gather, you will
| never understand how people use your product as well as
| actually speaking to them.
|
| The tech industry really needs to get over its fear of other
| human beings.
| zer00eyz wrote:
| Early in my work life I had a job on the UI side of things.
|
| Watching people use your app behind a 2 way mirror was
| probably the most illuminating thing ever. Users from outside
| the tech bubble have a very different take from most of the
| HN set. It influences how the look at, use and think about
| applications.
|
| You can watch 7 people DO the right thing and then tell you,
| out loud, that it sucks for the same reason. Every app is
| filled with problems like this. If you aren't testing with
| "inexperienced" end users you are likely missing a LOT!!
| garrickvanburen wrote:
| Fully agree.
|
| Early in my career, I ran these sessions.
| Moru wrote:
| This was even covered in our school. Test your program on
| your classmates, and then the rest of the school. This was
| way before smartphones though, it had to be in the computer
| rooms.
| htrp wrote:
| If you're yelling that they're using it wrong, you're doing
| something wrong.
| progmetaldev wrote:
| This is exactly correct. The software should be adapted
| to the usage patterns of the users, not for developer
| ergonomics. If the two happen to align, that's great, but
| it's a rarity.
| Terr_ wrote:
| Sometimes it's a "McNamara fallacy", where there's just too
| much emphasis/bias towards quantitative data.
| Chilinot wrote:
| This is exactly why i as a manger want to assign bigger
| projects on new hires. They have fresh eyes, and are not used
| to things we do just because we have always done them in a
| special way. It's interesting to see how they solve tasks,
| before they get used to the status quo.
| Moru wrote:
| And then grab some people off the street to test your
| product. Let them play with your app. Treat them to lunch,
| interview them while eating :-)
| progmetaldev wrote:
| I feel the same way. It's interesting how someone new to
| something tackle issues compared to yourself that has been
| doing things a certain way for so long. I've definitely
| picked up new skills just by watching less experienced
| developers use their own way to handle issues, and I make
| sure to let them know when they've inspired or led to my own
| gain in knowledge. I think it's a positive feedback loop that
| strengthens a team.
| AnimalMuppet wrote:
| A year ago, I got hired at this place that is, shall we say,
| less than stellar at teaching their new hires about their
| custom, specialized code framework.
|
| _Of course_ only new hires notice. Maybe only new hires who
| have been enough places to realize that it doesn 't have to be
| this hard...
| atoav wrote:
| It ia true that everybody can fall into that trap. Becoming
| blind to weird quirks of your own product is the equivalent of
| a senior professor becoming blind to the fact that the stuff
| they need to explain is hard to fresh students.
|
| The thing is, that not all people suck equally bad at this. A
| big part of it is to actually care and be empathic enough to
| put yourself into the shoes of the un-initiated. Two people who
| both have used the Bash shell a million times might have a
| completely different understanding of what makes it weird and
| unintuitive to someone starting out, even if both had trouble
| when they themselves did.
|
| Looking at things with a fresh mind is a skill one can get
| better at, just like you can learn how to look at actual light
| and objects to draw what you see instead of drawing what your
| brain tells you you see. It is a hard thing to learn and it is
| something that can fail you even once you became somewhat
| decent at it, but every good educator needs that skill.
| pjdesno wrote:
| I worked at a tiny self-funded startup once where we required
| new hires to update the documentation and processes to fix the
| problems they encountered during onboarding. That worked great
| with 12-15 people; not sure how it scales.
| sethammons wrote:
| We have done that at a few orgs that have scaled up to
| hundreds of engineers
| Lalabadie wrote:
| I do this as a freelancer who onboards with new teams pretty
| regularly. I've only had positive feedback from sending PRs
| that fix or improve the documentation on my first days with a
| project.
| smeej wrote:
| I tried to do this when I joined a new company. Problem was
| there were four other guys on the team, all of whom thought
| the correct process was different, not just from what was
| documented, but from each other's, and would go back and
| re-"correct" things after me.
|
| I spent the whole 3.5 weeks I worked there starting fights
| and noped right back out.
| vineyardmike wrote:
| I worked at a MegaCorp, and we required all new hires to (1)
| teach the next hire our architecture, core user journeys, etc
| and (2) the new hire had to present their learnings to the
| team, standing with their (quiet) teacher.
|
| Both of these steps were crucial. The presentation serves a
| ton of purposes, it ensures both the student and the teacher
| learn the material enough to present with a whiteboard, and
| the team can catch any mistakes or misunderstandings at a
| time when they'd have the most sympathy towards ignorance. It
| also is a good low-stakes way to force someone to present and
| get used to the team and talk to everyone in a formal
| setting. We also always ordered pizza + beer after too make
| it a "fun" (or at least casual) environment that wasn't too
| serious.
| closeparen wrote:
| Ease of onboarding and usability for new team members was very
| important during ZIRP when headcounts were exploding and people
| were changing jobs for 40% raises all the time. I'm not sure
| it's going to be such a useful optimization target going
| forward.
| m463 wrote:
| https://en.wikipedia.org/wiki/Shoshin
| hinkley wrote:
| I believe in the First 100 days phenomenon but I vigorously
| ignore any bullshit about fixing major tickets within n days of
| starting at a company. First of all many places I've worked
| were deluding themselves about the feasibility of doing this.
| Their onboarding process inhibited any such wishes when I
| started there.
|
| I've been doing user studies on developers for more than a
| dozen years. It got a lot easier once screen sharing was more
| common. But letting new hires or devs with brand new machines
| twist a little when going through the setup docs and taking
| notes. Or doing similar when I've made a major change or
| introduced a new API to see what fresh eyes see that I did not
| (or in some cases, that which was true but no longer is).
|
| If at all possible I task them with fixing the docs. First, as
| you say, they don't have the Curse of Knowledge, so how they
| word it will reach down the ladder behind them. Second, if what
| they say is completely wrong, then I can correct the
| miscommunication easier when they've used their own words to
| repeat back what we discussed.
|
| Making edits to the wiki is usually the first contribution I
| want to see from a new hire. Even if it's just untangling a run
| on sentence.
| thomastjeffery wrote:
| It's not always the staleness of perspective that is the
| problem. Often it is your personal opinion (the perspective
| itself) that is _both_ right and wrong.
|
| I think the greatest mistake in software design is the pattern
| of structuring UI/UX around _assumptions_. Every assumption
| made in software design is a _demand_ for the context that that
| software will be used. The reality is that context will always
| be fluid, and that it will often contradict itself. Free
| software can be liberated from its assumptions, but it requires
| redundant work for every unique contextualization.
| Nevermark wrote:
| You are only new once.
|
| But I expect starting a journal like this, waiting for a list
| to grow, is also a great path to resensitizing oneself to all
| the potentially useful problems to solve.
|
| Writing down something and then waiting is such an immediate,
| low effort/immediate reward (my list got longer!), but long-
| term high-payoff act, I think it can be easily relearned with a
| systematic practice like this.
|
| I like the continuous separation of recognition and recording,
| from the downstream progression: Create a map (see), take time
| to study it (learn), form a party of the co-concerned (lead),
| before running off into the forrest.
| HenryBemis wrote:
| I recently interviewed with a mega-big bank for a role that I
| 'got it'/I have the 20y of experience on the thing. I've
| talked to 4 people. I usually ask "what are the 3 things that
| you want to see me do/not do in the first 6 months" (among
| other questions. Person #3 said "don't ask to change things,
| observe for the first 12 months, and on the 13nth month raise
| your hand and speak up, not before".
|
| I have been journaling like for (8 years). Both notebooks and
| Scrivener. I like Nat's journaling method. This way he avoids
| looking like a fool/jumping the gun, and he gives the time
| for things to unfold (or not).
| kh_hk wrote:
| Always a good idea to keep a work journal, but there's something
| on the tone of this article that bothers me. I would like working
| with someone that is not a borg and is not following a script
| that seems taken from How to win friends and influence people. In
| general I will mistrust anyone that tries to manipulate me, that
| is, if I catch them doing it.
| spencerchubb wrote:
| What about the tone bothers you? I've never read How to win
| friends and influence people. I thought the article is pretty
| well-written
| lopatin wrote:
| Not the parent, but what bothers me is how the author tries
| to spin the idea of taking notes when you're new as something
| profound. He even gives it a catchy name "WTF Notebook". And
| the connection between creating a reputation of a fixer at
| the company, and taking notes with a WTF journal, is weak. I
| usually don't like to hate on articles like this and instead
| ignore them, but since you asked, it mostly sounds like
| bullshit to me.
| colonwqbang wrote:
| Writing things down and thinking them over before acting on
| them, isn't bullshit. There's other decent advice in the
| article. I think your review of the article is overly
| negative.
|
| Perhaps these techniques come naturally to some people, and
| others need to learn it by instruction? I'm in the latter
| camp. I often need to think about how I sound and make sure
| I don't come across as too negative.
| kh_hk wrote:
| I will quote specifically some examples of what jumps out to
| me as manipulative behavior:
|
| > I'll ask why things on the list are that way, and how they
| got to be that way. I'm trying to establish credibility as
| someone who's genuinely curious and empathetic, who's
| patient, and who respects the expertise of my coworkers.
| That's the reputation that's going to let me make changes
| later.
|
| I would not try to establish credibility, but earn it. I will
| not try to be genuinely curious or empathetic. I either am,
| or am not.
|
| > At this point I'm looking for one or two problems that have
| been bugging one of my new teammates for a while, and that
| have relatively simple solutions. I'm looking for something I
| can put on the retro board and know I won't be the only
| person who's bothered by that problem.
|
| This screams to me as playing the work game. If someone can
| spend time looking for problems over their coworker shoulders
| or "something to put on the retro board" it just means they
| are out of meaningful tasks to do.
|
| > Then, during the team conversation about the problem, I'll
| identify something that teammate suggests as an action item
| that we could try immediately. That way the team starts to
| see me as someone who helps them solve their problems.
|
| Change the context and this sounds like a pickup artist
| explaining dating tricks, or a con man telling you how to
| infiltrate or someone on the secret service trying to enter a
| gang.
|
| > The feeling that I want to create, the association I want
| people to have with me, is, "Oh, Nat joine [...]
|
| Feelings are not something one goes around creating unless
| they are actively manipulating people around.
|
| > There's a very specific reputation I want to have on a
| team: "Nat helps me solve my problems. Nat get things I care
| about done." That's the reputation that's going to get me the
| results I want in next year's performance review.
|
| I could keep going on, but I think these are enough examples
| Vegenoid wrote:
| I don't agree. You should only do things that benefit the
| team if they are done out of a true sense of cameraderie,
| and pure desire to empathize and solve problems? Not
| everyone has natural empathy, and people who don't have it
| learning how to do it in a way that benefits them and the
| people around them is positive.
|
| Re:'It sounds like a con artist', the techniques for
| getting people to trust and like you are often the same
| whether your intent is good or bad. I don't think these
| techniques should be reserved for people who have an innate
| wellspring of curiosity and cooperation.
|
| This person is trying to earn credibility, and is
| specifically focused on the 'new' phase of being on a team,
| when you do not have a big pile of meaningful tasks yet and
| your primary goal is getting the lay of the land and
| establishing good relationships with your teammates.
|
| Finally,
|
| > Feelings are not something one goes around creating
| unless they are actively manipulating people around.
|
| I don't really understand what this means. I create
| feelings all the time, intentionally and unintentionally. I
| often do things where the primary purpose is to make
| somebody feel good, usually things like 'make some effort
| to solve a problem that I don't think matters' or 'let
| somebody explain something to me that I already know
| about'. It's not about gaining power and status, it's about
| greasing social wheels and making friendly cooperation
| easier.
|
| Am I 'manipulating' people? Well, I am often trying to
| influence them so that they act in a way that I believe
| will benefit both of us. I do want to rise in my career,
| but I want to do it by making positive impacts and
| relationships, not by stepping on others. I don't think
| that's a bad thing.
| heisenzombie wrote:
| I think your reaction is common, your mindset is one that I
| recognize in myself and causes me many insecurities in
| relationships both personal and professional.
|
| However, it's worth saying that: Being intentional about
| relationships is not manipulation.
|
| If I decide "I want to be a better husband" and then spend
| time noticing and writing down a list of things that my
| wife says bother her or would make her happy or she thinks
| would be romantic, and then I go through and choose some of
| them and set myself reminders in my calendar to do them...
| Am I "manipulating" my wife into "thinking" I'm a better
| husband? Or am I just plain being a better husband?
|
| Would it be worse if I got the idea from a book titled
| Would it be better if, instead of being so intentional, I
| just let my passions and romance sweep me into doing
| romantic things without any conscious thought? Why?
|
| To make my point clear: Being very intentional about
| relationships (how others perceive and feel about you --
| and what actions you take to make them feel and perceive
| you that way) is not manipulation. If I act in a way that
| makes my coworkers think that I'm a good coworker, then I
| AM a good coworker! The fact that it was on purpose and not
| accidental is...?
|
| Manipulation happens when you develop your "be-a-good-
| coworker" skills (which is good) and then use those skills
| in a way that intentionally hurts your coworkers or makes
| them act against their interests (which is bad).
|
| I see evidence in the article of the first but not the
| second.
| AriedK wrote:
| It's a fine line. Maybe it isn't necessarily
| manipulation, but it does come off as disingenuous to me.
|
| To take your marriage example. The genuine motivation
| would be: "I acknowledge my flaws and I'm willing to put
| in the effort to change myself for the benefit of my
| wife". If the motivation is to just tweak your wife's
| views of you, that may not be manipulation but it's not
| very loving either.
|
| People will be able to sniff out if the goal of his
| behaviour is to have people think of him a certain way,
| versus having the goal of wanting to bring beneficial
| change and helping a team out. The behaviour may be the
| same on the surface, but the intent is very different. I
| would be very wary of judging people's motivations, but
| the fact that the author explicitly mentions it bothers
| me.
| dogman144 wrote:
| You hit on the most interesting aspect from this. I will
| explain what I noticed and I'm interested in how this viewpoint
| lands.
|
| First, the author is doing 101 new leadership stuff. I've done
| it, I've seen it done, there's a science to it. I can distill
| the whole blog post into when taking over leading something (as
| an experienced IC, as a new manager, as an army officer, it's
| all the same), take the first 30-90 days to not change
| anything, and just seek to understand how and more relevantly
| why things work. There are a mess of organization benefits to
| this, it would take more than a comment to explain why. But in
| short, ya this is how it's done.
|
| Second, engs have worked for awful managers, can't often
| understand or exactly place why but they know their manager
| sucks. I can argue capably in thread about how often this
| difficult to explain "sh*ty manager" sense boils down to the
| manager not doing like tactically good leadership. In the same
| way as engineering is a taught skill, so is leading teams.
| Issue is only a few places teach it intentionally. Top of mind
| for me is the military, and senior exec training. There's an
| actual science to it, full stop. You either get taught it by
| orgs that treat it this way, or you pick it up from a mentor
| who learned it somehow. Note - the author learned it this
| second way. This is really common.
|
| Third, to work for good managers, you actually want to work for
| good leaders. Leadership is a tactical skill, the same way
| efficient lines of C++ are. Leadership tactical means
| tactically shaping and steering people to achieve a goal
| greater than the sum of the team's individual parts. This full
| stop requires what in a certain light is what you point out -
| it's a bit manipulative feeling. It's using leadership methods
| to make people work together in a way that is effective. A lot
| of this is good EQ and stuff like the author maps out.
|
| So, who do engs like working for? Often it's working for
| technically inclined good people who go to bat for their team
| with external parties, shield their team from stupid stuff,
| resource the team to complete its goals, praise in public
| criticize in private, give good but not overly micromanaging
| guidance on where to steer things, recognizes and rewards
| performance, holds unperforners to a standard, and so on and so
| on?
|
| Some examples of who knows how to do this but for the wrong
| reasons are people engs don't like working for - to stereotype:
| charismatic jocks out of MBA programs who can know nothing
| about tech but know corp politics and deploy this stuff
| tactically.
|
| Who do engs hate working for often - technical hires promoted
| into management and they hate/are bad at their jobs bc
| management != tech chops, as my above covered.
|
| So, what that leaves is a scenario where teams are led by the
| occasional person that inherently knows good leadership chops,
| or more often it's pissed off engineers who hate working for
| someone manipulative or incompetent.
|
| To raise the collective industry odds that tech teams work for
| skilled and competent leaders, that leaves as the solution
| spelling out tactical leadership - how to do it, what it looks
| like, how people fit into it, like this blog does.
|
| Pick your poison - more of the same, or good people who just
| need clear guidance learning from resources like this on how to
| run teams people want to work on? HN certainly complains to no
| end about the dynamic caused by not approaching leadership as a
| skill vs some nebulous thing people somehow know how to do.
| d0gsg0w00f wrote:
| Yeah, my first thought was "how often does this guy change
| jobs?"
| toss1 wrote:
| >>I'll ask why things on the list are that way, and how they got
| to be that way. I'm trying to establish credibility as someone
| who's genuinely curious and empathetic, who's patient, and who
| respects the expertise of my coworkers. That's the reputation
| that's going to let me make changes later.
|
| Seems like an excellent corollary to Chesterton's Fence, about
| someone who comes upon a fence they want to remove:
|
| "If you don't see the use of it, I certainly won't let you clear
| it away. Go away and think. Then, when you can come back and tell
| me that you do see the use of it, I may allow you to destroy it"
|
| Or, more explicitly: "Although this looks out of place, we do
| best to assume that those who came before us were intelligent,
| and there is a reason for it. That reason may be obsolete, but it
| must be accounted for or we'll simply repeat a mistake."
| ChrisMarshallNY wrote:
| Or you could just go to the Daily WTF: https://thedailywtf.com
| hyggetrold wrote:
| Don't say you, say we.
|
| https://thedailywtf.com/articles/Behavioral-Deficiencies-
| neilv wrote:
| The writer gives a very honest-sounding description of their
| strategizing, and the rationale for that. And there's also some
| good advice about being judicious about what issues you raise.
|
| At the same time, this sounds very political, and not traceable
| to goals of the business:
|
| > _There 's a very specific reputation I want to have on a team:
| "Nat helps me solve my problems. Nat get things I care about
| done." That's the reputation that's going to get me the results I
| want in next year's performance review. That's the reputation
| that's going to get me a referral a few years from now._
|
| I like to be on teams for which, if new to the team, mostly you
| notice things being done sensibly (in context), and the 3 things
| you see that you don't understand, you can just ask about them,
| because everyone on the team just wants to work well together to
| achieve the genuine goals.
|
| Not to have to bank observations as an asset, to be introduced
| diplomatically and strategically, according to a script, to
| maximize performance reviews and peer approval ratings.
| throwaway35777 wrote:
| > _I like to be on teams for which, if new to the team, mostly
| you notice things being done sensibly (in context), and the 3
| things you see that you don 't understand, you can just ask
| about them, because everyone on the team just wants to work
| well together to achieve the genuine goals._
|
| I've observed this kind of culture mostly at startups. Once
| places start to make a lot of money -- things become political.
|
| So if you want to work at the highest paying jobs, you'll have
| to deal with politics. Because once they make enough money to
| afford you, the company also makes enough for savvy gatekeepers
| to entrench themselves in a core system and carve off a piece
| of that revenue for themselves.
| tombert wrote:
| I sort of did this with the management at a large company I used
| to work for. Whenever they'd do something that I thought was
| incompetent and/or sociopathic, I'd just write a bullet point in
| a file called `bullshit.md`. The file got to about three hundred
| bullets.
|
| I eventually stopped this because it kind of made me feel like a
| sociopath and/or narcissist myself. I don't really think it's
| healthy to keep tabs on everything that pisses you off, like some
| kind of scoring system. It's not like me writing this stuff down
| helped anything, and it just felt like I was trying to keep score
| so that if I get in trouble I have a retort. I think it's
| actually good to occasionally forget stuff and let it slide,
| because there will _always_ be bullshit management policies at
| pretty much any company with more than like four people, and
| writing this stuff down just makes it easier to let stuff
| continuously bother me.
|
| ETA:
|
| To be clear, it wasn't my idea to write it down, I was getting in
| trouble for complaining too much at this job, and my direct
| manager suggested I write things down. I think he thought it was
| a way to cool off, even though I don't think that was the effect.
| prakhar897 wrote:
| The biggest reason i've seen is because management hasn't
| prioritized it. It takes a few scars before understanding the
| importance of these tasks, pushing for them prematurely can be
| really risky. Letting stuff fail might be a better path for
| consensus.
| MajimasEyepatch wrote:
| Yes, the people who set the priorities have to feel the pain in
| some way. If you as an employee want your boss to do something,
| you have to communicate it in a way that makes clear how the
| problem will affect what the boss cares about, not what you
| care about. Usually that means translating it into dollars or
| one of the boss's KPIs, like deployment frequency or support
| ticket volume.
|
| Sometimes management doesn't prioritize problems because
| they're short-sighted or overwhelmed. But sometimes it's
| because they just don't understand how big a problem it really
| is, and the team fails to communicate it to them effectively.
|
| For example, I've heard devs complain about how "the tests take
| too long." On one team I was on, a couple junior devs were
| complaining about this, but it turned out that "too long" meant
| five minutes. Could they be more efficient? Maybe, but getting
| that down to one minute would take a lot of work with no impact
| on our ability to develop and deploy multiple times per day.
| Once I showed them how to run their tests locally on just the
| files that changed, the problem was solved. But before that,
| they thought the problem was "technical debt," when really it
| was just a training issue. (Or, you know, a lack-of-ability-to-
| Google issue, but I'm trying to be generous.)
|
| On another team, when I heard this complaint, the team
| explained that the full test suite took almost an hour, and
| flaky tests meant that they often had to rerun the tests or
| merge with failing tests. Needless to say, this had a clear
| impact on our ability to deliver rapidly with high quality, so
| this was something I prioritized.
|
| Managers don't do the same work as you, so they don't feel the
| pain firsthand. And they're often not incentivized to care
| about the same things as you, at least on the same scale. As an
| IC, you tend to be focused on the next task at hand. The
| manager is thinking about their quarterly OKRs or whether the
| team is on track to meet their sprint commitment. If you want
| something to change, you have to connect the problems you have
| on the micro scale to the problems the manager cares about on
| the macro scale.
|
| And if you can't do that, or your manager won't listen, then
| yeah: let the problems bubble up until the manager feels the
| pain, as long as it won't come back to bite you.
| BatmansMom wrote:
| The article is good, but as an aside, wow thank you for the
| introduction to "the bullet journal". Seems like an awesome time
| management tool.
| onthecanposting wrote:
| I wish I had read this a year ago. I kept a mental note of pain
| points in the workflow, played it cool for four months,
| researched solutions to the problems, then when I got a shot as a
| task lead on a fresh project, I jettisoned the rituals and was
| way ahead of schedule while nobody was looking. Two months later
| the neurotic hall monitors found out. Oh no, sir. You don't just
| thumb your nose at practices that were pioneered in the 1990s
| just because they quintuple the cost of work. You will be made to
| do it _our_ way to atone for your arrogance. You will use my
| ancient excel spreadsheet and tell me how much you like it.
|
| Now the project is financially a total shit show, I'm besieged by
| dweebs, and I've been quietly looking for a new job for 6 months.
| Apparently, this was an avoidable situation.
| l33tbro wrote:
| Interesting. Why do they want you to do it the old way? Or
| could you explain more? I've never worked somewhere like this,
| so curious as to why this would happen?
| Havoc wrote:
| >There's a very specific reputation I want to have on a team:
| "Nat helps me solve my problems. Nat get things I care about
| done."
|
| Managed that...would not recommend. When you're in a large
| organization and word spreads that you're the guy that can sort
| out issues...that goes viral and not in a good way.
|
| Recently had a guy reach out to me from Serbia for a solution. I
| didn't even know we had a fuckin office in Serbia let alone some
| guy there wanting a slice of my time.
| tantalor wrote:
| Interesting take. Let's just say, one of these approaches sails
| through the promotion process, and one does not.
| breckenedge wrote:
| Only if you're not pigeonholed.
|
| That promotion is going to need a backfill and the
| organization may decide that it's best to keep you in your
| place. Though it could lead to being able to negotiate a
| raise earlier than normal.
| jjeaff wrote:
| This idea, I think, is a huge hole that most organizations
| have. Which is that salary is too tied to hierarchical
| structure. If you have someone that is amazing at doing
| something valuable, they should be able to keep getting
| raises without necessarily getting promoted out of the
| role. We have this in some measure with jobs that are
| easily commission-able, but it's not common for tech roles
| or HR or whatever.
| kreetx wrote:
| It's the law of people being "promoted to incompetence" -
| the Peter Principle.
| Havoc wrote:
| >promotion process
|
| That's the thing. You don't get credit for those death by a
| thousand cuts queries that come with a universal X is the
| person with the answers rep.
|
| None of my superior knew we had an office in Serbia
| either...let alone crediting me with "yes havoc is totally
| flooded but he helped serbia guy anyway".
|
| Note that I'm talking general corporate here. Things may be
| different in a pure SWE eng context. My observation is
| strictly corporate life...may or may not extrapolate to SWE
| context.
| tantalor wrote:
| Peer feedback!
|
| "Without Havoc, project FooBar could not have happened"
| bityard wrote:
| I was that guy at my previous job, and had a much better
| experience.
|
| For starters, at that company, I always fortunate to have a
| manager that had my back when it came to deflecting requests
| that didn't come from him or her. If a random person reached
| out to me with a request to do some non-trivial work that I
| either didn't have the bandwidth or interest to do, all I had
| to say was, "Sorry but I don't have the time to look into this
| right now. If you need this prioritized, please run it by my
| manager." 99 times of 100, my manager never heard from them.
|
| The biggest upside to being the go-to guy for people across the
| department/company is that you get to collect acquaintances and
| contacts. It's a fun little micro-superpower. Extremely
| valuable when you need some bit of info from someone outside
| your team, or need someone to cut through some red tape to get
| something important done. It means I also have a modest network
| of people to hit up when I go looking for new opportunities.
| (This is how I have landed 100% of the jobs in my decade and a
| half of civilian employment.)
| AdrianB1 wrote:
| "There's a very specific reputation I want to have on a team:
| "Nat helps me solve my problems. Nat get things I care about
| done." That's the reputation that's going to get me the results I
| want in next year's performance review. That's the reputation
| that's going to get me a referral a few years from now."
|
| This works for a referral, but it is a career killer. I did this
| for 20 years in different departments. Every time they wanted to
| keep me there to solve their problems, but this never puts you on
| the promotion list. I had a colleague that retired after 40
| years, he was the go-to person for any problem, but he was never
| promoted, he was way more competent than any of his managers and
| their peers. He was the ace in everyone's sleeve, rarely
| recognized (it was considered to be "normal" that he solves any
| problem) and never rewarded; his performance was considered an
| expectation, while the rest of the people at the same level had a
| much lower bar. In the last performance review, his manager said
| that his performance is compared with his goals and targets, not
| with peers. I was told the same by a different manager, so it is
| not an accident.
| officialchicken wrote:
| I've kept a series of notebooks for my career starting prior to
| dot com 1.0.
|
| Looking back, over all that time, all of my notebooks tend
| towards WTF.
| havelhovel wrote:
| I've never been on a team where we've needed a new IC to come in
| and assess our inefficiencies, question priorities, and lengthen
| meetings with debates we've already had. There are plenty of
| management consultants available for that. What we wanted was for
| an IC to come in and help us meet our goals by churning out more
| code. There's lots of talk about reputation but no mention of
| value.
| marcofiset wrote:
| Removing technical debt and improving tooling is often a good
| way to add value. Sharpening your tools makes you work faster.
| havelhovel wrote:
| These things can add value, but no one needs a new hire to
| point that fact out. I'm also skeptical that a freshly hired
| IC's values will align with business values, even though the
| latter is what shapes the tech debt and tooling you're
| referring to.
| karmajunkie wrote:
| I've seen plenty of teams who didn't think they needed someone
| to evaluate what they're doing and just thought they needed
| someone churning out code.
|
| If they'd had someone do the former, most of the time they'd
| not have needed the latter quite so much.
| havelhovel wrote:
| What's more likely: a team of equally experienced engineers
| is waiting on a new hire to identify and fix significant
| blind spots or a team just needs more bandwidth to get things
| done?
| karmajunkie wrote:
| in my experience, while teams are rarely "waiting around"
| for a new hire, it's the outside perspective that makes the
| most significant improvements to process, tooling, and
| impact, and teams that resist the notion of blind spots
| that suffer from them the most.
|
| but maybe that's just me.
| NiagaraThistle wrote:
| Wow. I was just telling 2 co-workers this week that I keep a "How
| the F" file on my machine. It is not exactly what the author
| describes, but it's very similar and includes all the "how th f
| do i do this thing again?" every time I run into a problem when
| I'm new to a team.
|
| I don't bring it to management's attention like the author
| suggests, but it gives me a perspective on what sticking points
| the team and company have that I need to work through over time.
| helloiloveyou wrote:
| I also always think this way. I Summarize it as be a doer not a
| complainer
| ChrisMarshallNY wrote:
| Well...I have found that we should be careful, when considering
| "solutions."
|
| Here's my take on it:
| https://littlegreenviper.com/miscellany/problems-and-solutio...
| progmetaldev wrote:
| When I work with new hires, or I'm working in an area a teammate
| is unfamiliar with, I will often have them sit with me to watch
| and ask questions of me. I always encourage them to bring in a
| notebook and take notes for anything that they might have
| difficulty remembering, or may need more clarification on at a
| future time. So far, I've found that every new hire or teammate
| that decides not to bring a notebook and write anything down,
| never lasts for long. I'm happy to answer questions and help when
| I'm able to, but when I start getting the same questions we've
| already covered multiple times, and I've already told them to
| write it down and they don't, my confidence in their skills
| starts to dwindle.
|
| In contrast, the ones that use the time wisely, and take notes
| end up getting fast tracked to architecting systems on their own
| (with my oversight and code reviews). Those are the teammates
| that I love to work with, the ones hungry for knowledge and
| aren't afraid to make mistakes (assuming they aren't hiding
| them). I'd say I get almost as much knowledge out of mentoring as
| the new new hires do from learning new techniques and technology.
| It can be extremely rewarding.
| cratermoon wrote:
| I've learned to do this as well, and as a consultant it's become
| part of my job, so I've picked up a couple of extra tricks.
|
| One kind of WTF that isn't usually obvious from looking is when
| doing what looks like a simple thing takes excessive time and
| effort. Sometimes, after a couple of weeks, you can see something
| that has been in progress but not completed for no clear reason.
| Oftentimes these extra effort things don't show up because the
| team avoids doing them unless absolutely necessary. It's worth
| asking a team member for a tour around something you know from
| past experience in similar situations should be easy and quick. A
| big tell is when the response to your request for a demonstration
| or explanation involves a need for someone to block out extra
| time or involve a specific individual who knows it best.
| markus_zhang wrote:
| Sounds good. I decided to create two WTF notebooks, one for the
| team and one for myself. I, for one, am definitely not one
| without errors -- plenties of them, actually.
|
| My first note would be:
|
| - WTF! I ate five Lindt chocolates (they tasted so good) during a
| intermittent fasting session. I should burn in hell.
___________________________________________________________________
(page generated 2024-04-18 23:00 UTC)