5

I'm a recent graduate who is almost 8 months into his first full-time job. It's a well-paying, non-entry level software engineering job at a medium-sized company.

However, over the months, I've been growing somewhat dissatisfied by the job. Reasons include:

  • Communication silos from the team level all the way up the ladder. Communication with other teams only happens through my boss, his boss, or through formal tickets. Based on my access to Teams, it's as if my team were the only one in the whole company, as the company doesn't have any general channels. The opportunities to collaborate and socialize outside my team seem far and few in between.

  • The product I develop for is built on an exceedingly complex in-house platform that was not designed for our purposes. Build and testing times can exceed an hour even for simple tests. Public cloud budget limits are routinely hit. Most of the code is undocumented or in broken English. In short, development is frustrating.

  • The team doesn't seem organized. Meetings are unfruitful; there's tension between the leads and the product team. Tickets are passed back or cloned at the last minute with new requirements. Key details in designs are outdated or left as open questions.

  • My manager and other leads are unresponsive, as they're in meetings all day. 1:1s get postponed or canceled frequently.

  • I don't feel like I'm growing in my career or in my technical expertise.

When I was in the job search, my goal was straightforward: secure a software engineering job. My two motivations were to start gaining experience in the industry, and to start earning money to be able to live on my own. The job market was hard enough then. But as time has passed, it's clear that I want to focus my time in opportunities that challenge me and let me grow professionally, especially cutting-edge research (such as in compiler and language design).

Though I've been suggested numerous times to start looking for another job, I fear being labeled as a job-hopper due to the short time I've been at this company. On the other hand, the resentments described above and the guilt of not doing something more meaningful with my talents are contributing to a worsening depression, according to my therapist.

I've already planned a vacation to ease my frustrations. I've been documenting and diagramming to help myself and others in the team in my spare time. I've maintained a level of optimism in meetings. What can I do to make the best out of my current situation? Should I tempt myself looking for new positions? Or am I simply expecting too much from my work life?

3
  • 2
    I wouldn't be concerned about the impression of job-hopping. You've been there 8 months. In addition, don't quit until you have your next job lined up. But absolutely start looking around. Oct 23 at 5:14
  • 3
    I wouldn't necessarily take it as a given that another employer will not have any of those problems, unfortunately…
    – gidds
    Oct 23 at 16:07
  • 3
    my goal was straightforward: secure a software engineering job - Nailed it. It sounds like that was not enough. It might be time to sit down and write down what your goals are before going on the next search otherwise you might just find yourself hopping around between unsatisfying roles. Oct 29 at 18:40
5

​I fear being labeled as a job-hopper due to the short time I've been at this company.

Not a problem for 8 month on your first job. A fresher gets at last one hall pass.

What can I do to make the best out of my current situation?

Sharpen your interviewing skills. Apparently you signed up for a job that wasn't a good fit for what you want. Interviewing is a two way street: you should learn how to ask questions that get to the heart of what it's important to you and learn how to interpret the answers.

Should I tempt myself looking for new positions?

You should certainly go looking, but not before you have improved your interviewing skills. You need to be sure you don't make the same mistake again.

Or am I simply expecting too much from my work life

Come on, that's just silly. Many people have successful and deeply meaningful careers in their life. However, there is no magic employment fairy that delivers the perfect job to you. That is solely your own responsibility.

You are off to a good start: you have a good sense of what you want and what you don't like. Next you need to learn how to match this to job descriptions how to assess opportunities through upfront research and interviewing skills. Its also a good idea to look critically at your own behaviors and work on one or two soft spots that may get in the way of landing or being successful at your dream job.

Good luck: there plenty of rewarding and meaningful jobs out there!

2
  • 1
    To build upon "Sharpen your interviewing skills", think back to your interview. What should you have asked about the negative workplace environment you found yourself in? Could you have seen this before accepting your job? If you couldn't, what question would you ask so that an evasive answer or an outright lie would've been needed to trick you into the position?
    – Nelson
    Oct 23 at 8:07
  • you have a good sense of what you want - I don't get that sense from this post. I see some complaints but not really any kind of direction. My advice was actually going to be for OP to write down what they want out of their career and what they're doing to achieve it (whether that is staying or looking for the next). Oct 24 at 21:12
1

Given that you have no idea right now how long you may need to stay in this job, this answer is to suggest what you could do to improve things while you're still in this position. (There's a lot - you may need to pick and choose your battles carefully.)

  1. Communication silos from the team level all the way up the ladder. Communication with other teams only happens through my boss, his boss, or through formal tickets. Based on my access to Teams, it's as if my team were the only one in the whole company, as the company doesn't have any general channels. The opportunities to collaborate and socialize outside my team seem far and few in between.

While obviously not something you can control, you and your team should be able to put in suggestions about improving collaboration with other teams. When suggesting improvements it's always helpful to record details of specific incidents where slow communication or lack of collaboration has caused a material and measurable impact on the organisation as well as what your team delivers, for example:

  • Work item blocked by lack of communication leading to a deadline being missed.
  • Miscommunication or missing detail leading to the wrong thing being delivered.
  • Time (money) lost due to work being done with missing or incorrect information.
  • Negative customer satisfaction due to communication delays

In all of these cases, include things like dates, how long the delays are, what specific impact these had to the business/project/customer, how much time was lost, what remediation needed to happen. The goal here is not to throw anybody under the bus but to highlight real problems within the company, and the need as well as potential benefits from improvement.

You could make some suggestions to management about ways to make the organisation more efficient when it comes to the projects and features being worked on, for example:

  • Daily catch-up meeting between the team leaders for information/issues which affect multiple teams
  • Scheduled regular catch-ups between people working on the same feature or "slice" of the product. (e.g. a daily 'standup' with a project/feature focus rather than department/team focus, to include the Business Analyst, Tester, Developer).
  • Communal Teams/Slack channels for discussing issues and alerting others outside of the team to things which will affect them.
  • Shared access to the team's backlog tool/space for tracking questions/issues on specific work items.
  • Centralised system for knowledge-sharing across the business (e.g. StackOverflow for Teams, Confluence, SharePoint, GitHub Wiki, etc.)

Try to be inclusive of your co-workers as far as possible because this affects them too - invite them to make suggestions about improvements and/or examples where they've encountered the same issues.

  1. The product I develop for is built on an exceedingly complex in-house platform that was not designed for our purposes. Build and testing times can exceed an hour even for simple tests. Public cloud budget limits are routinely hit. Most of the code is undocumented or in broken English. In short, development is frustrating.

Entire books exist on how to work in such an environment (Get used to it -- working with technical debt and legacy code is a core part of being a software engineer). I'd highly recommend reading Michael Feathers' Working Effectively in Legacy Code. If it doesn't help you in your current job, it'll help you in your next one.

A few ideas of things you could look at:

  • When working in a particular area of the code, look for opportunities to improve its automated tests.
  • Start a backlog of technical debt items (if there isn't one already) for the technical problems that need fixing -- use this as a starting point to try to make the case for improving the system's maintainability.
  • Start an issue log which records each specific incident where someone on your team spent time (Make sure to record how many hours/days!) investigating and fixing problems caused by technical debt (which includes external dependencies and the environment/infrastructure). -- Use this as a way of identifying your greatest risks and "pain points" so that the business can see where time/money is being sunk.
  • Investigate the possible improvements and tools which could reduce the amount of time spent on supporting and maintaining the system. (Start on low-hanging-fruit if possible, for example, improved diagnostic logging or better analysis tools, improved failure detection, automatic recovery/failover, automatic notification upon failure. Indeed, a lot of tooling and "DevOps"/automation can lead to quick-wins or open up new opportunities to do things in better ways).
  • Capture the bottlenecks where developers lose the most time to try to estimate how many total "man hours" a single developer (or the entire team) loses each week/month due to the technology or development process (includes issues with tooling, broken development/test environments, long build/test run times, long and error-prone manual procedures, etc.)
  • Investigate possible improvements that could streamline the development process, again low-hanging fruit if possible (for example, project structure changes to reduce build/test time, any automation or scripting for long/tedious tasks)
  • Investigate possible improvements for quality - for example, improved code analysis tooling, workflow/process changes around source control and code review, improved testing/test data, CI/CD improvements, more representative development/test environments.
  1. The team doesn't seem organized. Meetings are unfruitful; there's tension between the leads and the product team. Tickets are passed back or cloned at the last minute with new requirements. Key details in designs are outdated or left as open questions.

These are issues that management need to be aware of and maybe intervene, but as a team you have the power to talk about them amongst yourselves, look at root causes and suggest (or even implement) improvements.

  • Keep a detailed log of problems the team experiences with tickets (Ticket number, date, description of the problem, what impact on the delivery/release) so that you can raise this with management -- leave out details of "who". Report upwards to management as a process problem once there's enough of a trail to clearly illustrate how bad/disruptive these problems are and what effect they're having.
  • Suggest that the company agrees a "Definition of Ready" for tickets -- i.e. a checklist of criteria for the ticket to meet before the development team can accept that ticket as 'ready for development'. For example: User story, Acceptance criteria, Wireframe/Mockup, No open questions, etc. This should ideally happen with the Product owner(s), Business Analysts, Developers and Testers so that everybody involved can agree on what a 'good' ticket looks like.
  • Also suggest a "Definition of Done" -- i.e. what the development team must do in order to pass a ticket into the 'completed' state (e.g. development complete, tested, peer-reviewed, automated tests written, successful green build, passed QA Testing, build/release number captured, etc.)
  • Suggest that the team has regular checkpoints/reviews (e.g. every 2-4 weeks) to capture and discuss the problems that impede the team and use this as a platform for continuous improvement. These reviews should be a chance for the team to talk about tech debt, process problems, recurring blocking issues, and anything else which affects the team that fundamentally isn't working, then to discuss what the team or the company could do to fix the problem, and take actions about fixing the problem or escalating it.
  1. My manager and other leads are unresponsive, as they're in meetings all day. 1:1s get postponed or canceled frequently.

While you cannot fix this yourself, your senior management can, and should.

Senior Management typically have objectives to identify and make measurable improvements to their department; they are likely to receptive if you present them with easily-measurable and quantifiable feedback on what's going wrong and why.

I'd suggest you keep individual records of the number of times delayed responses have impacted your work, and try to encourage your co-workers to do the same.

Improving a situation like this often requires senior management to be presented with clear data which shows negative/harmful trends affecting the smooth-running of the business.

If you can provide measurable, quantifiable data, then it's far more likely that those at the top will take note and attempt to fix the problem, although success depends on everybody continuing to keep track of whether things are getting better/worse/no change.

  1. I don't feel like I'm growing in my career or in my technical expertise.

Situations like this can be opportunities to forge your own path to growth; engineering is a discipline about problem solving and while many of the problems you face are not inherently technical, you're clearly in a situation with a lot of problems that need solving, with seemingly nobody else even making the effort to grasp or acknowledge them, let-alone fix them.

With that said, a lot of 'process' problems can be improved with better tooling and more automation. If you can get buy-in from your organisation (basically by convincing them that these problems are real, quantifiable, measurable, backed up by data, costing them real time/money/reputation, and even getting worse over time), then you have a foundation to work from, hopefully look at technical solutions which can start to turn the ship around, and a way to be able to measure any improvements.

The recurring theme with any kind of improvement is that the more measurable data you can gather about a problem, the easier it is (usually) to convince management that these problems are real and worth caring about; then continually measure so that you can demonstrate how your solutions are actually having a (hopefully) positive impact.

There may be a lot of scope to be able to suggest new tools or provide some scripts and other hand-rolled solutions which could improve the way your organisation works -- being the one to identify problems and make suggestions might land you in the position of volunteering to define the solution.

-2

I'll completely ignore what you dislike about the job. But unless you have rich parents or a rich spouse willing to finance you, you'll have to do the job until you start a better job elsewhere.

Follow Dale Carnegie's advice: Since you have to go to work and do the job anyway, you might as well enjoy it. All the problems you mentioned are things you can just ignore (as long as your paycheck arrives in time). In the morning, put on your happiest face, don't worry about getting work done, so that pointless hour long meeting is just time for you to relax. If you have to wait for a response, that's time to practice something new.

Do people expect you to be productive in your environment? Obviously not, or top management would tell middle management to tell your manager to make his team more productive. So don't worry about anything, you can do what's expected from you with little effort. Come to work happily, leave happily, use the free time in between for learning and for job search.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .