Episode 311: (rerun of 207) Unclear career goals and garbage code

Soft Skills Engineering - Podcast autorstwa Jamison Dance and Dave Smith - Poniedziałki

Kategorie:

In this episode, Dave and Jamison answer these questions: I’m a senior software engineer at a fast growing software startup. In the past year and a half that I’ve been with the company I’ve gone through 5 reorgs and have had 5 different managers in 4 different teams. Each time I sit down to do a 1 on 1 with a new manager they ask about my career goals and aspirations. Initially, when I joined the company I was a weak and feeble non-senior software engineer. When I was asked this question then, my answer was “to learn and grow, and have more authority and autonomy over the systems that I build, and be considered a senior software engineer”. Over the past year and half I have proven my worth and paid my dues and got the title of senior software engineer, along with the pay raise that came with it. My career development horizon has not been very broad. I didn’t even know there were levels beyond senior software engineer for a long time. I feel like I’m missing out on growth opportunities by not having a clear answer to this question. Please help! Love your show, keep it up. I career switched via a coding bootcamp 3 years ago and have been at my current company ever since. The bugs created by my garbage code from the early days made me a big believer in clean code practices — I now feel strongly about using descriptive variable names, avoiding duplicate code, etc. However, my boss/CTO is on the opposite end of the spectrum. As long as the code works, he doesn’t care what it look like. I want to stay at this company because I strongly believe in the product and I love the flexibility of a small start-up, but my boss and I keep bumping heads. For example, we recently switched over to PRs, and each PR my boss has made included blatant violations of the coding standards document we created together (!). When I request changes on the PR, he says he’ll do it but it isn’t a good use of our time to rewrite it when the code works. My question is two-fold: (1) As the most senior engineer on the software team, how can I go about promoting a quality-driven approach when the CTO doesn’t see the value in it? (2) If all else fails, I’m open to quitting, but I don’t want to end up the same boat. During interviews, what questions can I ask to find out if the company truly values code quality?

Visit the podcast's native language site