Comment by zeroq | Hacker News Reader

Comment by zeroq | Hacker News Reader

|> Your team (and manager) sees you're working

That's one of the greatest corporate flaws and my biggest personal failure that I fail, and refuse, to adapt to.

When I work in a team I often try to empower lacking teammates by taking a challanging task, do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution. While working on it they have to understand how the solution actually works (for instance by writing tests), and usually they are happy that they can contribute something bigger than they normally could. I don't mind passing the credit, as long as I know that the person actually made some work and understand the code. Meanwhile I offer myself for help or pair programming (although I'm not really a fan of the concept per se) to kickstart someone elses tasks, helping with architecture or just the general approach to the problem.

My coworkes like me, it worked wonders when I was running my own company, yet, when working in BigCo I have to constantly explain myself to higher ups that I'm actually present, not slacking and doing my job, because my jira/github profile doesn't shine.

One could say I'm a fool by not building up "portfolio" and paving my way to promotion/raise, but I genuinely think that this brings much bigger value in a long run. :)

this comment resonates with me. I think it’s a common mistake for a lot of folks to forget that programming is a creative task, and creative tasks rarely fit into metrics effectively. I have a bad habit at my place of work for not ticketing things out correctly and pushing larger than average commits.

At one point I just realized that the work in BigCo has very little to do with actual value, and much more politics and PR. In my last workplace we had two teams working on almost identical applications - large, multistage web forms for insurance. At that time it was a common practice at the office to estimate in units of time. One team was constantly commiting sprints to 300 units and delivering 200, and the other was commiting to 100 and delivering 150. First was quickly disbanded and fired, and the latter was praised for performing beyond expecations.

> do most of the hard work, and give it to somebody else to finish up the easy part and ship the solution

once I realized that the hardest part is actually _finishing_

Maybe for you. I'm terrible at starting projects and the beginning of them, but I love getting all the pieces in place and getting the product/feature to a production-ready state. It's easy and natural for me.

I used to work closely with a "starter" who is great at getting the activation energy to start, and we made a great team. Find yourself a "finisher".

Also, as a senior employee, I found that just general technical and even organizational troubleshooting was difficult to quantify or even justify (in formal management-style terms), and did not really form any kind of "portfolio". Oh well.

Reply on news.ycombinator.com