Ask HN: How do I keep up with work?

It sounds like you already know the problems to be fixed, so you need to talk to your lead and manager in order to fix them:

1) Use a linter and stop discussing spacing and formatting.

2) Start sizing tickets... or stop an unreasonable expectation of the same delivery for different scopes.

These are standard discussions that most teams sort out early on in a project. So maybe another way to look at this is that you have one underlying problem - you never communicated as a team to agree upon expectations. A 4 person team is way too small to be having these kinds of conflicts, so I'd work on improving communications and helping everyone get to a healthier place.

Has your manager actually told you you aren't delivering fast enough? Or is that just a perception you have?

If you're not involved in the sizing or estimation then don't commit to any dates and don't bow to any pressure over dates.

In my experience pressure to deliver fast is never enforced. It's all talk used to squeeze and bully people and by incompetent managers who don't know any other knob to turn. Consider this a psychological game. Don't play into it. If you don't deliver by the dates chosen by your manager nothing will actually happen.

In my career whenever I've been faced with the choice between speed and quality I have always regretted it. Even when managers and everyone around me said otherwise. I have never, not once in my 20 year career, actually been punished for good quality even if that meant being late.

> I also get a lot of comments on my MRs about minor issues like spacing or formatting which only my tech lead cares about. Unfortunately my manager considered this as a bad thing.

I'm actually with your tech lead and your manager on this one. It is imperative that all team members are using the same code style. Its part of your IDE's settings.

While it is fun to debate tabs vs spaces, camelCase vs PascalCase vs snake_case, private _members vs private Members, but in the real world, you match the style of the project you are working on. Always.

> Our tickets are expected to be done in 3 days and we don’t do sizing or anything.

Can you split the tickets? Say "this is actually made of two tasks: X and Y".

> minor issues like spacing or formatting which only my tech lead cares about.

Try discussing it with the tech lead. Why not using a code formatting tool? If it's not possible, ask them how they visualise those issues.

For instance your IDE can show you (or even fix) "weird" whitespaces (e.g. tabs vs whitespaces, whitespaces at the end of a line, whitespaces on an empty line). Maybe your tech lead has such tooling already?

Here are some suggestions that may be of use:

* If tickets are supposed to be "done" in 3 days, you might find that people are happy if, after 2 days, you have some part completed/merged/released, and a new ticket(s) for the "rest" that is clearly described, detailed, etc. Rinse and repeat. Now, everything is "done" in 2 days, and you're exceeding expectations, and the new manager has a victory to talk about at the next meeting.

* For spacing, figure out how to configure your IDE, or some pretty-printer / indent tool that does it how the tech lead likes it. Obviously, "tabs vs spaces" or how to to format or whatever doesn't actually make any difference to the running code or anything else, so it's not worth arguing about, and no argument about it can ever actually be "won" because it's all personal preference, so if you just do it how they prefer, if that's what they want, they'll be happy. They probably regard this as being about "attention to detail" or being a "team player" as much as being about tabs vs spaces or whatever they say it's about. Start putting comments on _other people's_ MRs to follow the style the tech lead wants when they drop the ball.

* If your fiance is sick, take proper time off when needed, give as much notice as possible, ask people to take notes / record meetings for you to catch up on. Don't let it seem like an excuse / card you play _after_ you drop the ball. Don't be available / working at 80% of capacity/expectations because of this at all times, be 100% capacity / totally on the ball when you are there, but sometimes be away / 0% present when you need to be, and then they'll miss you when you're not there, and appreciate you when you get back.

It's possible you are too far gone at your current job, but maybe not... in any case, you'll find these suggestions apply anywhere. Obviously, deep down, we all know these metrics and tabs vs spaces and stuff are silly, but this is how companies work. These things can be gamed, so be the best at gaming the system, and everyone will be happy. If you fight it, you'll lose. If you don't like it... figure out how to start your own company :) 4k users is impressive, maybe you're closer to that than you think.

> I also get a lot of comments on my MRs about minor issues like spacing or formatting which only my tech lead cares about. Unfortunately my manager considered this as a bad thing.

This is a problem with your manager. He should provide a pre-hook or a PR action that reformat on pushes. Sure, you can't have everyone using a different formatting convention, that would be insane (especially for diffs) but everyone should have his own formatting on his own IDE.

Anecdotally, nearly every time I’ve had a change of manager, replacing the one I originally interviewed with when joining the company, I ended up quitting in less than one year, typically because I couldn’t deal with their management style. It always seemed silly that, after working my ass off, now I had to prove myself again to a new manager. Might as well jump ship and get a good raise for it.

So no advice but you’re not alone.

>> I also get a lot of comments on my MRs about minor issues like spacing or formatting which only my tech lead cares about. Unfortunately my manager considered this as a bad thing.

I'm not sure I can help you with your bigger questions, but this part is worth a comment.

When I started programming I measured results by "does it work". The cosmetics of the code, and indeed the UI in general weren't terribly important to me.

I came to understand that being fastidious about the code sent a signal about the quality if the code. I was showing that I cared about the details -and if I cared about those details I cared about the details of the problem I was actually working on.

Likewise, customers only saw my UI. If it was ugly, they assumed the program code was buggy. Clearly that's a false assumption, but it follows that if my UI is sloppy then my code is sloppy.

If you are getting bad feedback in your review, take it to heart and improve that part of your game. It may not be important to you but is important to others (and when you get to do code reviews in the future you'll likely understand why.)

No one is perfect. No one "keeps up" all the time. But mostly your manager wants to see you improving, adding value to the team. Which means playing by the team rules.

Good luck - I hope the situation improves for you.

First, let's talk about surviving death by metrics.

You need to be thinking internally about why things aren't getting done faster. What are your bottlenecks? What is slowing you down? In your mind you should be done with an assignment in roughly 2 hours and frustrated when the assignment takes longer. If an assignment does take longer than 2 hours write down why. You can keep this to yourself if you have to, but it is better to expose this as a series of comments on your work item.

If you are slow because internal processes are slow and you have to wait 10 seconds between each mouse click you have a serious problem that is beyond your control. You need to be screaming about this with anger, because apparently your job is at stake. If you are in framework hell that requires 10 steps of unnecessary stupidity to accomplish what can be done in a line of code otherwise you have a serious problem to be angry about. If you are slow because solutions to the programming logic do not instantly come to you then you have a cognitive problem that may or may not be solved with extended practice outside the office. Whatever the issue is you need to write it down for your own personal metrics so you can keep ahead of the office metrics.

At my last job everything was slow and everything was full of regression. I was slow because the product was incompetent with logic stuck between SQL insanity and framework hell. Furthermore, I was constantly fixing regression from other developers. I lost that job and didn't really feel bad about it. At my current job I am absolutely crushing it. Even with a low work ethic my productivity is extremely high and they promoted me before everybody else. It is not about how hard you work but what you accomplish.

---

Second, let's talk about the job market.

If you want to be employable then have what employers care about. You really need to ignore what is popular for developers. Things that helped me find employment (I don't have all of these, btw):

* security clearance: secret, top secret, common public clearance from the FBI, and so on

* security certifications: security+, CASP, CISSP, and so on

* business certifications: PMP, Lean 6 Sigma, business titles, and so on

* education: bachelors, masters

* diverse years of programming experience: product design, architecture, test automation, A/B testing, and so on

* writing skills: blogs, published articles, published technical documents, and so on

The ones that landed my current job were the diverse years of programming experience, security clearance, and security certifications. What earned me the latest promotion was leadership, writing ability, and productivity. For me the goal before the promotion was to do as little work as possible and be otherwise invisible, which meant getting work done quickly in the best possible quality so that I didn't have to revisit it.

[dead]