Hacker News Reader

Want interesting work? Don’t expect to get it assigned to you, you have to find those ideas. Then you have to convince others it’s a valuable investment. In short you need a little bit of sales skills to put yourself in a position to propose and “win” the cool work.

The best way to do this is with “show don’t tell”: make quick and dirty demos of what you’d propose. A demo with kinda working code is far easier to make decisions about than some giant proposal of an idea. And don’t just sit on it until you see your boss: get feedback from colleagues about your idea before anyone else. Either the enthusiasm will snowball, and you’ll have allies when going to management on why doing this work is essential. Or it’ll sputter out, and that’s a valid signal too!

Also:

> the team is so large that it's often easy for him to lose track of an individual developer.

This jumped out as a bit of a red flag. Sounds like you’re doing your best but can’t get anyone’s attention. That’s frustrating. In many work environments this isn’t the norm.

So you are assigned to write tests which you consider tedious, but you want to work on the main code base presumably on features. Here are my thoughts:

1. Always deliver the goods: Execute your assigned work to the highest quality. To help with mindset, instead of thinking of your work in terms of "effort", think in terms of "contribution". Great tests contribute substantially to the quality of the product and prevent future regression. Find ways to deliver some bonus improvements, for example: improving coverage, improving test speed. Demonstrate that you create value in the team beyond what is assigned. Again thinking in terms of your contribution helps ie. contribute above and beyond what is asked.

2. Document the value you add and highlight it to your team and manager. Don't be passive about it. Building a reputation of quality and reliability as an engineer will help you navigate this project and beyond.

3. Be direct and clear about asking for work that you are interested in. Don't be passive. Passive is weak. Top performers are not passive, they are clear about their goals and direction and go after it directly.

Hope this helps. Good luck!

This hits hard. I entered a new position being passive/humble and now it's difficult to turn it around

Testing is real coding! It's just not glamorous, but testing is one thing that every developer should do although many don't. Maybe you could carefully refactor scary parts of the code base after writing lots of tests for it. Like others have said, make a case for the refactor to your direct report. Good luck!

1. Look for what interests you most about what you are doing now. Focus in on that and do the best you can at it. Learn some things around it. So, if you're writing tests for something but you realize the thing you're testing could be better, lean into that.

Alternatively, just do your work but pay attention to what others are doing and talk to them about it. See what their pain points are or what they don't have time to do, and see if that lines up with something you're interested in. Either way...

2. Come up with some interesting ideas that can benefit the business. Keep it simple and do your due diligence. Do some little experiments using around 10% of your time, or during time you're not expected to work (yeah, it goes against the anticapitalist program, but it's a great way to get ahead.... Anyway, you're a knowledge worker not an assembly line person).

3. Try to get buy-in. Bring up the problem that you're solving and be ready to provide the solution along with your due diligence or even a prototype. You might only get a "keep looking into this" but that's your toe-hold :)

This was my basic strategy at the job I had before officially becoming an engineer. I was sooo tired of filling in simple reports, and I realized that I could probably automate it. I took a risk and spent some of the time I had alone at the office writing a script to make some batch edits.... And it worked! Then I was able to get buy-in to build a GUI for it. So if I was able to do this when my job description wasn't even "engineer", I know that you can do it as a SWE :)

Great tips.

when i am distributing work to software engineers, i try to assign work based on strengths, preferences and business needs.

if i were you and wanted to work on something different, i would first understand the business needs and the project and then tell the person who is managing the work what i wanted to work on in a polite manner.

e.g. if the contract is for QA work on a desktop app, then asking to redesign the thing on mobile isn't going to fly.

Write the best tests possible. Believe it or not, the other work is tedious too.

Recycling some replies. More context on https://news.ycombinator.com/item?id=26182988:

- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)

- https://news.ycombinator.com/item?id=26591067 (testing pipelines, scaffolding, issue templates)

- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)

- https://news.ycombinator.com/item?id=22827841 (product development)

- https://news.ycombinator.com/item?id=20356222 (giving a damn)

- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)

- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)

- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).

- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)

- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)

- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)

- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)

- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).

- https://news.ycombinator.com/item?id=24177646 (communication, alignment)

- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)

- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)

- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)

- https://news.ycombinator.com/item?id=25922120 (researching topics)

- https://news.ycombinator.com/item?id=26147502 (keeping up with a firehose of information)

- https://news.ycombinator.com/item?id=26123017 (fractal communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets)

- https://news.ycombinator.com/item?id=26179539 (remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align)

>No real coding, just testing.

Testing, or reading the tests, is a really good way to know a codebase. It's valuable. It enables the team to move with confidence.

>Maybe software engineers that haven't been performing at high levels are mostly given the job of testing code

Don't read too much into it.

>it's just a standard to have certain developers do all of the testing

The next phase will be new commits including tests.

There are many ways to go about getting what you want. One of them is to be very helpful for the team and the project. Write good tests. Write tooling to make life easier. Make metaphorical buttons so people can push them and magical things happen.

On top of your "testing duties", own the product. Improve it in any way you can. Fix a bug, implement a feature, add great docs, refine the copy, think of ways to make it more profitable, make it more stable, think of integrations, extract useful bits into libraries. This is not for everyone and the decision is yours to go above and beyond or not.

>P.S. hope I didn't complain too much, but if I am just let me know :)

One definition of a problem is when there is a gap between a desired state and a current state that we do not how to remove. You have a problem, in that there is a gap between your desired state and your current state that you do not know how to "bridge". If this were a more thorough effort, we'd probably be talking about what is it you really want, and what the "actual" thing you're looking for is, but ...

People will gladly let you deal with more complexity once you have demonstrated you can handle more complexity. You of course can take a stand and wait to be given more complexity before you have shown you can handle more. I am not going to get into a conversation about how "just" or "unjust" this reality is. I am just telling you how to change it quickly. It may not be popular and it's understandable and to each their circumstances but, often, if you do what most people do, you'll live like most people live.

Ask HN: Software Engineers – How to overcome being assigned tedious tasks