Clojurians Log v2

I haven't been "on the market" for quite some time, so take it all with a grain of salt, but I also don't think anything had any reason to change. In short - by itself it means absolutely nothing, only the context brings meaning. Every single job that I had treated the words "software engineer" differently, as well as "senior software engineer". Job 1: Everyone starts as a software engineer, which means you can program to some extent. Do your tasks well enough and don't break things, and you become senior in no time. Hardly any new responsibilities, just a bit of extra knowledge, skill, and common sense. Job 2: There are no seniors, only regular engineers, and all of them have those responsibilities that you mentioned. One of the many reasons I quit after just 2 months. :D Job 3: A very explicit career ladder. You can ask for the metrics and optimize for them yourself - one of the colleagues there got promoted from "an engineer who just finished his bachelor's" to "a senior software engineer" within a year. There were things like being able to manage two other people, have reasonably accurate task estimations, have reasonable amount of skill and domain knowledge at least in a particular slice of the project - all reasonable things.

There are better jobs than what you describe, but also worse ones 😝 Generally a senior engineer is expected to do one of two things: 1. Be the full owner of say the most important system on a team, they know it best, most impactful projects are assigned to them, they don't really mentor others, or get involved in dev methodology and team processes, etc. They're seen as the person that you give the important work too from the point of view of the manager, and can trust they just get it done on their own. 2. They are team lead or team lead like. They are expected to figure out what to do, plan for the work, estimate, contribute to decisions on what the team should do, not do, and how to do it. Make sure the team is working efficiently, getting the right things done, delivering on team expectations, mentoring, improving team processes, etc. In this one you will be a product designer, project manager, team manager, stakeholder liaison, software architect, etc. You probably will struggle to ever write code, but will still be expected too. You'll have way too many meetings, etc. It can be good if you're truly given the authority to succeed, but often you'll be stuck in politics and endless debate. It can also be good if you work with a good product person, manager, etc.

#2 leads to Staff Engineer normally, where you are slowly more on the business side with a foot on the engineering side, and you're more and more pushing for broad strokes, everyone change to micro-services, everyone use AI more, etc. And starting to talk about KPIs, goals, and all that MBA stuff.

I am (on paper) a “senior engineer”, though I’ve seen “senior” job postings range from mid-level to principal-level, depending on the company, so at the end of the day it really depends on who you ask. At my job though, a senior is responsible for all those things: leading projects, interacting with customers, gathering requirements, mentoring other devs, feature development, infrastructure management, as well as all the in-between stuff. In previous jobs, I had also experienced varying levels of burnout and quickly realized that was not sustainable health-wise. Some things I think contributed to that burnout: • Pressure from management • Pressure from clients • Poor project estimation • My own ambition And a few strategies I took to avoid TOTAL burnout: • Pushing back on management and clients “The team cannot reasonably deliver X in Y weeks… but here’s what we can deliver” • Estimating more pessimistically • Time boxing myself to only 40 hours (or whatever a standard work-week means) and signing off after that. Another thing I remember was doing work that felt like burnout, but was really just a feeling of emptiness/meaninglessness. The work itself wasn’t the kind of work I wanted to be doing, or I was fixing an issue that was just going to show up again a week later, so doing it felt tedious and pointless. All those little in-between things I’ve also noticed can stack up quick. When providing estimates, I’ve sometimes had to cut my effective work-week in half to account for everything else: meetings, code reviews, maintenance, prod support, the tens of 5-minute calls / messages and other mid-day interruptions. Hope that offers a little bit of insight.

For the future, there's a #C0KL616MN channel where this sort of conversation has played out a few times, so there might be some good information if you search that channel. I'm on my phone but this is a very interesting conversation, and I have thoughts which I'll write up tomorrow!

The only thing I am pretty sure about is that this is not sustainable health wise.

And it's not only the amount. The nature of the work is very important. For instance if a senior/lead/whatever dev is constantly given Operational tasks like "generate credentials" or "check if an email went through" or "fix bug with client data for the fifth time" then they will be hurt from these too. So the more senior you are the harder these hit.

I do not consider myself a senior software engineer, but i have worked with and managed software engineers for a long time. Perhaps the most important tasks of the job is to get three things right. 1. Focus the team (and the company) on things that truly matter 2. Be realistic about tasks and challenges and push back hard on planning or goal that are not achievable 3. Enable your team to do the right things. Let them take responsibility (trust and verify), and ensure they too work in the same manner If you feel that you are overwhelmed, then now is the time to think and act (as you are doing now with this message!). It begins by trusting yourself and what you know you can and cannot do. And then push back. Create room and space to do the job that needs to be done. Good luck!

I've held titles of software engineer, senior software engineer, software architect, senior software architect and now "CTO" and boy, I do not expect anything anymore 😄 The context of the work varies too much and it is really tightly bounded to the company culture. So, it dependes, is my answer. Now, basically what you @aaronrebmann described is what I do now and then some as a CTO of small company. I do take responsibility of anything that falls out of the hands of others. I manage anything from service subscriptions to writing and approving ict policies, assist the CEO with the company board etc. I do get a final say on some matters but that is not a significant part in any way of my job. I ensure that everything works, improves and evolves towards meaningful goals. This is basically what I have been doing my whole career despite the titles, salary and recognition.

If you are feeling overwhelmed then its likely you're already burnt out. Take some personal time, at least a week, ideally 2 weeks. Switch off from work and anything software engineering related (easier said than done). When returning to work, spend the first week identifying what the real needs & priorities are and push back on anything that doesn't have well defined value for the company. Delegate as much work as you can, as ths will create a natural bottleneck (pipeline) of work which highlights there is too much work for the current level of resources. Also consider carving out 1 hour a week to review your career development, assess your skills and current limitations. This helps with your own sense of worth, identifying skills to acquire or hire and also help you write a good CV. You sound like you are doing a senior role, plus product manager, team lead and engineering manager. This experience will help get a better role at a different company if you feel the current company does not support or value you sufficiently.

I think I should add that in my current role the responsibilities are huge but the upside is that I'm one of the owners of the company, so I can justify the role quite easily and I am working for myself. I chose this when joining a startup.

> When returning to work, spend the first week identifying what the real needs & priorities are and push back on anything that doesn't have well defined value for the company. Very very important. Don't "just take" the original workload. I know this.

@aaronrebmann You don't say anything about the size of the company or the industry you're working in, but from your description of the team, it sounds like there's no separate QA or ops folks, and possibly no separate product management folks? In which case, the entire software lifecycle falls on you and your colleague (and those two, maybe part-time, freelancers). That's the sort of thing I've seen at startups that have grown quickly without revenue directed at expanding the team, which indicates some poor top-level management: of course developers will get burned out in that scenario. Even in a well-run startup that aggressively hires people to build up those missing areas, developers often get burned out. Startups can be brutal, and startup life is not for everyone. Been there, done that, and I stopped dealing with startups over a decade ago because of it (I've been in this business for over 45 years at this point). If where you're working is not a startup but an established company, then it's poorly run: it's failing in the way those startups fail that don't expand their teams, and don't support their employees. In either situation, if you feel burned out, and that this is not for you from a health p.o.v., be assured that there are much less stressful software environments out there, but also possibly much less interesting to you—depending on why you became a software developer. Are these "reasonable expectations" for a "senior engineer"? Not in a large, well-run company, no. As others have noted, job titles are pretty meaningless. In small companies, they tend to be just vanity titles, and in large companies they often fall into an HR-designed hierarchy based on salary bands, that have nothing to do with your actual day-to-day job. Software is a fast-paced industry (in general) so people often move through junior -> standard -> senior in very short order, and I think that's a real shame. As someone who has been doing this for over four decades, and has been a hiring manager for over three decades, I think we've lost sight of what it takes to learn and grow in software. My personal feeling is that you're a "junior" developer for about the first five years of your career. Then you're a regular developer for the next five. And then you might be a "senior" developer after about ten years in. And that's assuming you are mentored and offered training regularly along the way. For context, the "10,000 hours to mastery" that folks often bandy about would be 40 hours a week for 50 weeks a year for 5 years. And we all know that a software developer doesn't spend all their work time actually focused on just the "software development" portion—and we have to contend with an industry where things change so fast that developing mastery of anything on the implementation side is pretty much impossible.

IMO your company lacks a product / sales / ops person and if your management does not understand that, one day you will be blamed from slowing down the product roadmap even though you are already committed 200% to the product. This happens regardless of scale (it’s a team organisations issue), if you are in a large company with a small team that owns a package you may encounter the same problem. Engineers have a tendency to say yes to customers, but the role of product is to say no (and suggest something better) to customers. It is very difficult to juggle both. As an engineer, I make it clear to my manager/founders/product folks that I am here to provide solutions and judge the feasibility of those solutions, not to judge which is right for the company/product, and I do not cross that boundary unless explicitly requested. On the question of “what are senior engineers”, personally I would view it this way Juniors: You fix problems you are handed. Mid-level: You find latent problems and fix them. Seniors: You fix problems in the future (If this is abstract, consider how the design of clojure fixes classes of problems in the future). Regardless of seniority, people and time are part of the equation. For example, taking a unreasonably long time to fix a problem as a junior, is the same problem as proposing a strategy to fix a problem that would take a unreasonable amount of people effort and time to fix as a senior.

I have no idea if such a thing as "reasonable expectations for someone who is a senior engineer" exists. That being said, as others pointed out, it seems to me like the problem is your current job/company, not you. My advice: try to remember what drew you to this industry, what you like to do and what you're good at. Then find another company where you can do that, keeping in mind any concerning flag about a foreseeable future burnout.

Wow, thanks a lot for all of that input. This certainly helps me to gain a more grounded view on things - on my own I am always swinging back and forth between "this is all my fault" and "this is all the cto's fault", neither of which is helpful. All of this certainly helps me to move towards a conscious decision and at the same time gives me a little strength boost that might keep me above water until I know what I am going to do about this. My takeaways in short, for the future reader of this thread: • You're not alone • It's okay to ask for help • There is no normal - a judgement of a conflict/environment/situation is meaningless without context • It's not about technology most of the time • The clojure community is super wholesome ❤️

My take would be it does not matter so much the responsibilities of the role, but what is realistically achievable over the long-term with the time budget you have, you can only do so much per day. After that you need to push back and ask about priority, what is most important now. The one trait of being a senior is saying "no", identify what not to do. Burnout is no joke. If you don't raise it with your manager they don't get the opportunity to help. Unless you are in one of the those companies who simply do not care and only want yes-people, then leaving is really the only option.