Hacker News Reader

> shut up for 6 months and just do whatever you're told

I've found it better if I don't shut up, I tend to ask a lot of questions. I still do what I'm told (that's what I'm getting paid for, ultimately), but the chance to ask questions is one that shouldn't be passed up.

The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?"

And, ultimately, every company is kind of fucked up. Each company is fucked up in a slightly different way. Accept this as your starting point, try and figure out why it's fucked up (your first 6 months), and then try and fix it by working with your co-workers (who, despite working at a kind of fucked up company are probably at or above the median for human intelligence).

Asking questions is an effective strategy - it comes off as wanting to learn rather than wanting to teach.

> The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?"

Absolutely. Ask questions, all the questions. Just be smart about it. There will be time later to discuss these things, and the company will have reasons. If the reasons are ones you can't live with, get out, but you're not in a position to affect real change at this point. But for me when a junior dev is asking questions, it tells me they are actually invested.

> Without knowing the full story, who knows what actually happened there Without knowing the full story, who knows what actually happened there.

Chesterton's fence:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "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."

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

No kidding. As someone who has a good bit of difficulty with social interaction (no diagnosis, but it overlaps with issues that ASD and ADHD people often report), I've failed a likability check or two in my time. I've had conversations where someone seems to be offended or otherwise put off and I have no idea why. But even having those problems, I don't discount other people's opinions and priorities so much that I'd just go in and refactor an existing system without first being pretty clear on who's responsible for it, what problems I'd be solving and risks I'd be creating for them, and that they're okay with it.

There's a risk to this approach. I tried it twice (with ~3 year gap in between), and twice I lost myself and had to re-train to be my usual self.

Bad habits are contagious, momentum gets lost. Conformity is a strong force.

I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns.

Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.

Absolutely agree. I will make the one addition that "6 months" as a time period for that "nascent" stage is actually a variable based on how quickly you can connect to the rest of the team. Size of the team is also a factor on this variable. For example, if you're on a team with 3 other people and you're a generally sociable, like-able, persuasive individual, that time period to ramp up and start affecting change on the team might only be a month. If you're a grouch, you might be looking at closer to 6 months for that same time because it's harder for you to win the team's trust. Nobody wants advice from a mean stranger but they will probably listen to their mean friend.

Size of the team is important as well. The example I gave was 3 other people on the team. Building a relationship with 3 people doesn't take a huge amount of time. But how about an engineering organization of 4 teams and 20 people? Well, now that's going to take quite a bit longer. It's also going to be more difficult and complicated as navigating multiple teams, initiatives, interests is obviously an order of magnitude more complexity than one team and 3 people.

"shut up for 6 months and just do whatever you're told. "

I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.

Sometimes a contractor, who has been on lots of jobs and seen everything, can tell immediately that things are not going well. They can see a way out. And 6 months is a long time to watch the walls fall in around you.

I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time.

Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things.

So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid.

Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.

My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions.

A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability.

If you are good you can make improvements in the worst code base without having to change everything first.

> This gives you credibility and trust. Then make your suggestions.

Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.

I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.

Yes, working with shitty code is part of the job. You can't refactor if you can't read other people's code, no matter how bad it is. It's still code, and it probably does something in production that's needed.

Sure bad code that works is defensible in a cost analysis.

But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere.

Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain.

I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.

I agree that there are just plain bad code bases that aren't worth fixing. But my point was that a lot of us (including myself) have a tendency to immediately dismiss what our predecessors did without having made an attempt to understand the situation.

Let's just say, assuming that you are a rock star and everyone else can't code is a poor starting point. I have been on the receiving end of this attitude, and it's not pleasant. These people just come across as arrogant, and they look really bad when they screw up right out of the gate. Some humility goes a long way, EVEN IF YOU ARE 100% RIGHT.

That's exactly it, professional experience opportunity cost and what you spend time getting good at.

That's ... eerily familiar. Almost as if you were sat in the same team as me.

Suggest some overall changes, which if they aren't taken seriously, increase your rate for the next six months?

I've approached the topic of changes, and been shut down each time. They've got so much on their plate, talking about design is the last thing they want to do apparently.

And yeah 'rate' at a large corporation is an intractable thing. My contracting company (I'm a partner) is billing through another contracting company, which is billing thru a billing company, which is contracting the client. The deal was, take this rate or take another job.

Which means, I've been looking constantly for another gig of this length or better. Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.

> Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.

The company agreed to (or set) your rate, they set the assignments, you've done due diligence in informing them of higher level issues, you have nothing to feel guilty about.

Things often have to hit some minima low point for larger changes to be considered. Hopefully they'll still have to resources to stay afloat while the change is enacted... but personally there may be little point waiting around for it unless you see an opening to where you can help at a higher level (and at a higher rate) and they're willing to accept it.

Honestly, I'd probably get out. Some things just aren't fixable. I'm in a similar situation now and really weighing just finding a better place, but of course there are some complications.

So it sounds like: you're a contractor (i.e. you are part of the most disposable group of people in the building), you have a fixed duration of work (presumably with an option to extend... but that's not a unidirectional option), as a group the contractors scope of work has been altered (from strategic to tactical), and your contract is almost up.

If this isn't what you signed up for and have other options, provide the customer of your intent to end the engagement when you have satisfied the term of the contract at 6 months (don't do it early, just give whatever notice is needed so you can end it on time). Don't assume that anyone there cares about your ideas on how to fix things or they would have asked you already.

One big caveat: if you're going through a 3rd party contracting company I've got some bad news for you... you probably never were there for the strategic work but rather to be a warm body to sit there and be billable so just put in your notice and move on. Worst case, you get offered more money to keep putting up with it (make sure it's a real increase... I'd go for at least 15-25%)... and if that appeals to you, enjoy some easy money riding it out for a bit longer.

As a new person, you may see things that are blatantly obvious to you, sort of this stranger effect, and half of the time you will be right.

The other half of the time:

* You are just wrong.

* The issue is already known to everyone but it has been deemed low priority.

* Things may seem wrong but they are that way for a reason.

So, pay attention, make a mental note of issues, but don't bring anything up in the first few weeks, as you may look at best silly, at worst, like a whiner.

The flip side, is that this is how deviance is normalized.

https://danluu.com/wat/

> Don't make any decisions, don't make any improvements to the company process, and don't argue with people

I disagree. Do these things, just do them in a subtle manner.

Nobody likes someone who comes to a new job and can't stop saying "at my old job we did XYZ in such a way". It's annoying and condescending.

Nothing wrong with hinting at improvements though. Trivial example: rather than "we should all be using rubocop", you could mention in passing that rubocop really helps you write clean code.

Expanding on something I mentioned in a different comment: I wish more managers were up front with the pain points.

If I can explain our refactoring/internal improvements road map, and give brief backstory about why the current state is the current state, and save someone weeks or months of "ugh is this code really the best thing we could be doing here?!" context-less fumbling, that's a great tradeoff.

I suppose it could backfire, if [new hire] immediately disagrees with my reasoning and comes to the conclusion that I'm just an idiot who's bad at that stuff, but is that really going to be worse to hash out some on day 3 instead of day 40? If [new hire] turns out to be an asshole who isn't open to other people's opinions, let me find that out ASAP.

6 months is VERY long though, in software development; if you have a six month trial period (which is also pretty long, although OTOH the more common 1 month here is pretty short), you also kinda have to prove yourself, to show to both your peers and the boss you're an asset. So yes, do start focusing on the actual business and such first, get a feel for the culture. If there's other people that e.g. submit cleanups / refactorings, then point out an issue and ask if you can take a bit of time to clean that up - for example, and assuming you don't have anything more important to work on at that time, etc.

RubyConf 2017: Keynote - You're Insufficiently Persuasive by Sandi Metz - https://www.youtube.com/watch?v=VzWLGMtXflg

>While I know I made many mistakes, I believe I was not the only one who did... but I was the one on probation... so... so long and thanks for all the fish.

Author seems somewhat arrogant, one of the worst personality traits in my opinion. Hard to be liked if you're arrogant.

Lol go king kong on their shit