_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI I keep a WTF notebook (2021)
cchi_co wrote 7 hours 48 min ago:
> I make a note every time I run into something that makes me go
"wtf,"
I need that type of note in my life
urbandw311er wrote 11 hours 49 min ago:
I like this article because itâs surprisingly humble. The author has
learned from previous mistakes and now has a solid process that
prevents him trying to fix everything unnecessarily while annoying
people as he does so.
buescher wrote 17 hours 47 min ago:
Also, when you hear real WTFs, try to keep a straight face.
hi_hi wrote 18 hours 30 min ago:
> 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.
This should be near the top of the article, not buried at the bottom.
This level of self awareness is a real skill that is worth mastering.
The ex astronaut Chris Hadfield talks about a similar approach he used
when joining new missions and teams in his book. Basically being in
observation mode first to learn if these WTF moments are valid, and not
annoying new team members. Its worth a read.
markus_zhang wrote 22 hours 43 min ago:
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.
cratermoon wrote 23 hours 6 min ago:
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.
progmetaldev wrote 23 hours 12 min ago:
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.
helloiloveyou wrote 23 hours 35 min ago:
I also always think this way. I Summarize it as be a doer not a
complainer
ChrisMarshallNY wrote 22 hours 50 min ago:
Well...I have found that we should be careful, when considering
"solutions."
Here's my take on it:
URI [1]: https://littlegreenviper.com/miscellany/problems-and-solutio...
NiagaraThistle wrote 23 hours 53 min ago:
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.
havelhovel wrote 1 day ago:
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.
JonChesterfield wrote 18 hours 25 min ago:
The existing team tends to be blind to stupid things they're doing.
There's a period of time where the new guy sees things and thinks
"wtf are you doing that for". Shout him down and you solve the
annoyance problem and add him to the list of people who no longer
notice the stupid things, or at least no longer try to fix the stupid
things.
Maybe your team is only doing sensible things and all is perfect.
Maybe you're blind to things that could be better. Heuristically, if
you're writing software, it's not likely to be the first case.
My professional project moved to GitHub recently. It is terrible. The
pull request / review system is borderline unusable. But already I
can feel myself adopting clumsy workarounds and losing sight of how
much better it should be.
karmajunkie wrote 23 hours 44 min ago:
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 22 hours 48 min ago:
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 22 hours 30 min ago:
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.
marcofiset wrote 1 day ago:
Removing technical debt and improving tooling is often a good way to
add value. Sharpening your tools makes you work faster.
havelhovel wrote 22 hours 30 min ago:
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.
marcofiset wrote 19 hours 5 min ago:
The point being is that new hires will bring fresh eyes to an
organization, whereas the team in place might be numb to some of
the issues.
You don't need a new hire to fix those problems, but it certainly
helps shed new light on some problems. Especially if you are
hired as a senior dev or a team lead, you will be expected to fix
some of those things.
officialchicken wrote 1 day ago:
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.
AdrianB1 wrote 1 day ago:
"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.
Havoc wrote 1 day ago:
>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.
hosteur wrote 7 hours 16 min ago:
Not sure why this is bad?
moe_sc wrote 1 hour 46 min ago:
Usually you are not employed to help out everyone, everywhere in a
team. Maybe such a position should exist in any large company, but,
yeah, I don't think it does...
riwsky wrote 12 hours 2 min ago:
Charge more.
klysm wrote 14 hours 41 min ago:
You have to couple this with the strong ability to say no
danparsonson wrote 16 hours 35 min ago:
The middle ground is learning how to be the helpful guy but also
being able to say no when you don't have time. Not easy, but
enforcing boundaries is an important skill.
bityard wrote 22 hours 8 min ago:
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.)
tantalor wrote 1 day ago:
Interesting take. Let's just say, one of these approaches sails
through the promotion process, and one does not.
Havoc wrote 22 hours 24 min ago:
>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.
EVyesnoyesnoyes wrote 11 hours 1 min ago:
I work in a big software company with 100k and i get asked about
stuff from people.
But i'm seen as knowledgeable and my manager basically lets me
completly alone doing my thing and gives me all benefits
regarding salary he can to keep me.
kstrauser wrote 17 hours 36 min ago:
Sounds to me like you've turned yourself into a Staff Engineer,
and should ask for that next review cycle. What I'm hearing is
that you're influencing the whole organization by enabling many
people to get more stuff done, beyond what you could be doing as
an individual contributor. That's a very, very good thing.
You can only write so much code per day. If you can help 100
people be 10% more productive, you're leveraging your knowledge
to help the whole company do 10x more than you could personally
do. Congratulations!
tantalor wrote 21 hours 53 min ago:
Peer feedback!
"Without Havoc, project FooBar could not have happened"
jh00ker wrote 18 hours 34 min ago:
We had a project FooBar? In Serbia?
baq wrote 12 hours 20 min ago:
"raised organizational awareness about offshore projects"
breckenedge wrote 23 hours 54 min ago:
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 23 hours 33 min ago:
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 22 hours 56 min ago:
It's the law of people being "promoted to incompetence" - the
Peter Principle.
onthecanposting wrote 1 day ago:
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 21 hours 42 min ago:
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?
onthecanposting wrote 15 hours 0 min ago:
The short answer is pride and inertia.
The immediate cause is lower management can't be assed to learn
anything, and nobody makes them. This is in part because at big
firms after 5-10 years you can politic or job-hop into management
and be an email engineer who does little outside of scheduling
meetings and marking up PDFs. Young engineer training is usually
informal and in master-apprentice fashion. Your mentor will show
you how he or she learned it 10 years ago, which is how his or her
mentor learned it 10 years before that.
There is little technological progress in civil engineering design
that is not externally imposed, and the last big step forward was
Excel and replacing hand drawings with CAD in the 90s. Digital
delivery will be the next leap, but it's going to take lobbying,
fanatical champions, and pure luck that Autodesk and Bentley don't
use their billions to suppress it.
Procurement laws, client ignorance, and network effects shield
engineering consultants from the discipline of the market. Wasteful
practice is not punished. That and licensing regulations have
created a sort of guild socialism that has allowed backwardness to
survive.
spyspy wrote 16 hours 14 min ago:
Im not saying I donât believe you, but Iâve never been anywhere
that wasnât at least a little like this. Thereâs always some
power tripping person using âthe way we do thingsâ as a club
against the newthought people
BatmansMom wrote 1 day ago:
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.
prakhar897 wrote 1 day ago:
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 1 day ago:
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.
tombert wrote 1 day ago:
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.
baq wrote 11 hours 47 min ago:
Don't call it 'bullshit.md', call it 'challenges and
opportunities.md', s/fuck|shit|cunt// inside and organize a series of
coaching sessions about how you fixed one of these and how can they
help themselves fix these.
or, channel your inner complainer into your promo-seeking behaviors.
tombert wrote 1 hour 8 min ago:
I don't doubt that that would have been the most profitable
solution to this for me, but that's really not my personality.
This is not a joke or sarcasm: I genuinely think I might be
slightly on the spectrum, because I have a lot of trouble with
corporate dishonesty, and there are plenty of times that I will say
things that are apparently controversial and I don't realize it.
For example, at that job, during a discussion about them getting
rid of a benefit that they used to pay for, I made the mistake of
once saying to higher-management that "we all do this job for the
money", and I got a bunch of indignant responses about how they
believe in the cause and all that shit [1]. I was really confused,
because I didn't even realize that that was up for debate; I'm
quite confident that if this company stopped signing their
paychecks, they'd stop showing up for the job and I really didn't
(and still don't) think that there's anything particularly wrong
with that. I'm selling my time and expertise, Tombert is a
for-profit enterprise.
When I tried explaining this to them, I get a private meeting with
one of my million managers above me that I have a "bad attitude"
and that I'm trying to "stir the pot", and I genuinely wasn't
trying to, I was just trying to make a point cutting through some
of bullshit flavortext to get to the point that getting rid of a
benefit that we liked does affect us because I was under the
impression we worked for money, not for fun.
I have a million stories like this, and it's why I suspect that I
will not be able to grow my career much more than I have right now.
[1] To be clear, this wasn't some non-profit, this was a very very
large for-profit company that you've definitely heard of that my
lawyer/mom has advised me not to directly name.
neilv wrote 1 day ago:
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 1 day ago:
> 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.
ChrisMarshallNY wrote 1 day ago:
Or you could just go to the Daily WTF:
URI [1]: https://thedailywtf.com
hyggetrold wrote 21 hours 16 min ago:
Don't say you, say we.
URI [1]: https://thedailywtf.com/articles/Behavioral-Deficiencies-
toss1 wrote 1 day ago:
>>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."
kh_hk wrote 1 day ago:
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.
d0gsg0w00f wrote 21 hours 0 min ago:
Yeah, my first thought was "how often does this guy change jobs?"
dogman144 wrote 21 hours 45 min ago:
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.
tibbar wrote 16 hours 51 min ago:
I think you nailed it here. It's important to internalize that
being a good employee (and/or leader) is not a virtue, it is a
skill. You can be a good person and a bad employee/teammate/leader.
A bad employee in the sense that you're letting other people down,
and/or a bad employee in the sense that you're not getting paid
appropriately or getting denied opportunities.
Your job is a really important part of your life - and you will
also affect a lot of other people. It's important to be a bit
strategic. Otherwise, even if you have wonderful intentions,
there's a great chance you'll work on things that don't matter and
that leadership knows nothing about, until your career quietly
fizzles out.
spencerchubb wrote 1 day ago:
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
kh_hk wrote 22 hours 55 min ago:
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
EVyesnoyesnoyes wrote 10 hours 59 min ago:
He thinks about those types of things and are acting on it (which
is the key point in my opinion) because he is someone who thinks
about those types of things.
I think thats a very good attitude.
cess11 wrote 11 hours 24 min ago:
I get where you're coming from, but in a somewhat large or large
organisation the organisation has a life of its own and it
couldn't care less whether you're authentically you or not. If
there is something to gain from throwing you out it will,
regardless of how you feel about it.
Hedging against that with conscious social strategies can be a
reasonable thing to do, at least if you are in or are likely to
end up in such a large organisation.
I've made the choice to be in a small organisation, in part
because my contributions don't need packaging and announcements
to become known to those with more power in it than I have. If I
were to change my mind and join a large organisation I wouldn't
think twice about entertaining a 'game', balancing the degree to
which I exploit other people and organisational weaknesses to
gain money and stability for myself against a semblance of
professional and personal ethics.
jptlnk wrote 19 hours 18 min ago:
Without imputing any actual intention to the author, I agree with
your points on tone. It feels focused on optics, not outcomes.
It's one thing to say that you want to get things done. It's
another to say you want to be _seen_ as someone who gets things
done.
Again, I don't intend to mind read here, and I think the author
actually has some really good data gathering ideas. But the
language definitely smacks of political motivation, which some
folks (myself included) find off-putting.
heisenzombie wrote 21 hours 53 min ago:
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.
hoc wrote 11 hours 49 min ago:
For some this might have a bit of sociopathic creepiness to it
which even seems more apparent in that marriage context than it
does in the original article of an "deeply" structured coder.
Of course control might be a valid goal, and controlling your
need to control might be a good meta step, too, in a
professional environment. The issue of the line between caring
and controlling just seems not been discussed enough. And not
seeing and mentioning that obvious emotional aspect might
already make it look a bit weird.
AriedK wrote 20 hours 48 min ago:
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.
richk449 wrote 15 hours 14 min ago:
The Turing test for husbands: determine if your husband is
actually a good person or if he is acting like a good person
so that you will love and appreciate him.
heisenzombie wrote 16 hours 13 min ago:
You say 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"
But... How do I know which actions will "benefit" my wife? I
argue that one of the best ways to know is to ask myself:
"Will this action make her feel positively about me?". That
way, I'm not going to do things that are important to me but
not her, or that I think she SHOULD appreciate but she
doesn't actually care about, or whatever.
Of course, to answer that question accurately requires plenty
of listening, understanding and empathy.
In the past, I thought more like you. But I think it harmed
me. Ultimately I came to the conclusion that intentionally
doing things so that other people like to be around you isn't
"disingenuous", it's a wonderful thing to work towards!
Vegenoid wrote 22 hours 25 min ago:
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.
lopatin wrote 23 hours 19 min ago:
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.
strken wrote 19 hours 10 min ago:
I think there's a strong connection between identifying and
fixing problems, and between fixing problems and getting a
reputation as a fixer.
colonwqbang wrote 21 hours 46 min ago:
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.
zer00eyz wrote 1 day ago:
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.
xnorswap wrote 11 hours 50 min ago:
You can get part way there with a sabbatical.
I recently took a 2 month break from work, and coming back I had
plenty of these moments too.
Things that previously I thought were smooth weren't. Processes that
I thought worked fine seemed to crumble. The overall application
speed felt like treacle where previously I thought it was fine.
Sometimes a fresher perspective on the state of things is important,
although unlike a new team member it's not doing me many favours
pointing some of this stuff out.
Being a new team member is also an amazing opportunity for being able
to speak freely about problems and point out that the emperor is
nude.
_carbyau_ wrote 16 hours 38 min ago:
I think TFA is more stressing that this only "new" once perspective
can lead you to exclaiming WTF a lot to all your new colleagues -
thus giving the impression of being a loud complaining nuisance.
Instead, by writing it down and NOT expressing it just yet, you give
yourself time to learn the lie of the land and why things are the way
they are; to orient yourself in the workplace. And when you are
comfortable, settled with accounts/permissions/authorisations, you
have a nice list to move on.
The team is then more likely to think you are being helpful rather
than a popup muppet exclaiming "WTF is that!" all the time.
jasonm23 wrote 16 hours 45 min ago:
But it's not us we just keep being let down by these new hires. I
don't get it, how are they all stupid or lazy?
- Many a myopic org
Nevermark wrote 22 hours 0 min ago:
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.
cchi_co wrote 7 hours 37 min ago:
> You are only new once.
Really comforting
HenryBemis wrote 21 hours 45 min ago:
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).
thomastjeffery wrote 22 hours 37 min ago:
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.
hinkley wrote 22 hours 48 min ago:
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.
m463 wrote 23 hours 58 min ago:
URI [1]: https://en.wikipedia.org/wiki/Shoshin
closeparen wrote 1 day ago:
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.
pjdesno wrote 1 day ago:
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.
vineyardmike wrote 22 hours 10 min ago:
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.
smeej wrote 22 hours 32 min ago:
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.
Lalabadie wrote 23 hours 32 min ago:
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.
sethammons wrote 23 hours 51 min ago:
We have done that at a few orgs that have scaled up to hundreds of
engineers
atoav wrote 1 day ago:
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.
AnimalMuppet wrote 1 day ago:
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...
Chilinot wrote 1 day ago:
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.
progmetaldev wrote 23 hours 8 min ago:
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.
Moru wrote 1 day ago:
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 :-)
reaperducer wrote 1 day ago:
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.
creeble wrote 3 hours 30 min ago:
I wish all companies did this. Even better, record the experience.
Itâs astounding how many UI developers never watch a real
customer using their product. All UI is compromise, but you see a
very different set of possible compromises when you watch someone
(particularly a new user) use the product.
My favorite is the whole âlet it be a user settingâ compromise.
If you donât get the âcorrectâ default, then a non-obvious
user setting does nothing. And if you do get the default right,
then you probably donât need the setting.
Terr_ wrote 20 hours 21 min ago:
Sometimes it's a "McNamara fallacy", where there's just too much
emphasis/bias towards quantitative data.
zer00eyz wrote 1 day ago:
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!!
htrp wrote 23 hours 59 min ago:
If you're yelling that they're using it wrong, you're doing
something wrong.
progmetaldev wrote 23 hours 10 min ago:
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.
chrisweekly wrote 18 hours 29 min ago:
Yes, this, exactly.
Swizec recently wrote about "desire paths":
URI [1]: https://swizec.com/blog/architecture-is-like-a-path-...
Moru wrote 1 day ago:
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.
garrickvanburen wrote 1 day ago:
Fully agree.
Early in my career, I ran these sessions.
sonicanatidae wrote 1 day ago:
I call mine a ticketing system. ;)
slimsag wrote 1 day ago:
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 better if ,
what do you think?' and make it a genuine discussion with people,
rather than 'WTF ?' - 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.
yjftsjthsd-h wrote 1 day ago:
Waiting a couple weeks makes sure you have enough context to usefully
contribute with less stepping on toes.
al_borland wrote 1 day ago:
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 1 day ago:
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."
lrvick wrote 1 day ago:
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.
okamiueru wrote 1 day ago:
I do something similar, except at one shop where the WTFs outnumbered
everything sane by a wide margin.
marginalia_nu wrote 1 day ago:
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.
arduanika wrote 1 day ago:
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.
ravenstine wrote 1 day ago:
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 1 day ago:
> 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; [1] I highly recommend you look at the 77th infantry
division in WWII: [2] Is an entertaining summary.
URI [1]: https://medium.com/illumination/late-success-is-possible-8...
URI [2]: https://www.youtube.com/watch?v=0Su5-_KuDf8
ravenstine wrote 22 hours 29 min ago:
> 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 22 hours 13 min ago:
>> 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"
xandrius wrote 1 day ago:
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 1 day ago:
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.
ergonaught wrote 1 day ago:
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.
mckn1ght wrote 1 day ago:
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 1 day ago:
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.
DIR <- back to front page