I'll echo that the UI design is cool. I do think it could be improved to help parse information. Right now, it feels like everything is bold, highlighted, italicized, or something denoting how important it is. This is made worse as every UI element is also bold and highlighted.
I built something like this at work using plain Docker images. Can you help me understand your value prop a little better?
The memory forking seems like a cool technical achievement, but I don't understand how it benefits me as a user. If I'm delegating the whole thing to the AI anyway, I care more about deterministic builds so that the AI can tackle the problem.
Good for you for trying to do right by your team, but oof. An entirely junior team with no tech leadership is going to have problems beyond mentorship.
For reference, 14 yoe and currently in management.
Today, I don't think the tools are good enough to make a material difference. It may help a bad engineer tread water, but it won't take you from good to great. It may save you time writing basic boilerplate and individual functions, but I suspect 99% of engineers don't struggle with that. What's hard about our jobs is knowing how to orchestrate the whole thing and put structure around complexity. AI can't do that yet.
When I use it personally, it feels like a harder context switch trying to describe in english what I already know how to code. Then I still have to review the function to make sure it's accurate. It feels like a waste of time and an additional context switch.
Whenever the AI gets better, we'll have to use it to be productive I have no doubt. But the pool of engineers will change too - there will be a categories of engineers who can't debug the AI output and who still write crazy prompts.
Maybe I'm old, but I'll only be worried about AI when it can write and maintain a full app with no human intervention.
Hopefully it will eliminate all the boring shit like managing JIRA, giving status updates, and following up with communication tasks. Another large part of my day is also troubleshooting random things, so hopefully AI will benefit my team before I have to get engaged.
I don't think AI poses a risk when it comes to setting engineering priorities and building the roadmap. If it could do that, it could probably just build the entire system anyway.
EMs are there for the human aspect of engineering, so I also doubt it will impact hiring or EM-engineer ratios.
I do expect the bar to being an EM to be higher as the job will be more technical and less project management.
When you say 'analytics database', what kind of performance are you implying? Massive queries that respond in 10min? How tuned were things for the queries you were running?
I'm currently working through an analytics architecture and I'm having to defend against "why aren't you using postgres" when I'm talking about olap dbs.
What process is going to help senior contractors understand the codebase they've been in for 2+ years? We can create spike tickets all day, but at a point, that's just a distraction.
Splitting teams with interconnected and related work, I do something like https://agilesquads.org/. For each sprint, we'll have a planning cadence where we scope 2 weeks of work e.g. Feature X and Feature Y. Each squad would get assigned a feature and they're able to focus on delivering that feature. The benefit of this over a real "split" is that you can have both "teams" working on the same roadmap/project/feature and/or change how many engineers are working towards a single feature. When you include "squad leads", it's also great for career development and leadership.
On product work, we do an oncall rotation of 1 engineer per week that triages issues and handles prod outages. This may solve for your 'help desk' type work.
That GMT offset is probably from your browser. The github API doesn't include timezone information.
If this is the direction you want to go, the only way I can think of determining this is by telling the contractor to use a github account you control and then monitoring the logged in sessions.
No, eng and product are separate orgs, but I'll work with them on process, documentation, meetings, etc. I'm a big believer in demonstrating value before asking people to do more work. So when I wanted product to do write more documentation, I did most of it myself to show the impact it had on engineering and how organized the team was. Now product owns it.
It's less about taking on roles and just doing what needs to be done. Everything is a partnership in building the product, so I help where I'm needed most. When our hiring pipeline dried up, I'm the one doing outreach. When our test suite needed enhancements, I'm writing demo code to show best practices. When an upstream service pushed breaking changes, I'm the one pushing for process/communication changes.
Granted, my current org is a little bit of a mess, but every place I've worked at needed me to flex because it gives my team the ability to do what they do best - code. And since I'm fixing processes and not a bottleneck, I have a stronger case for promotion too.
I'm at a tech company as an EM. My primary responsibility is making sure my team is delivering high quality software. Sometimes this means my job is documentation, testing, being a PO/PM, or recruiter. I have to know the codebase to communicate and organize things, but I rarely have time to code. My days are spent in meetings and when I'm not in a meeting, I'm writing slack messages to other managers/teams or analyzing problems.
As a manager, you have the freedom to set your own schedule and run your team the way you see fit. I don't know if I'd recommend that when you first start out, but you're judged based on the outcome - generally. Some managers still do 50% coding, which is fine, but I think those pitfalls need to be considered carefully.
Once my teams get to a self-sufficient status, we're able to take on more responsibility and do more "innovation" type projects. That's "success" in my mind, but it takes time to get there. Up until that point, I do whatever I need to.
fwiw, I'm currently ending ~6mo of time off. I'm further in my career, 15 YOE and in management. I didn't plan this and only did it as a result of joining a toxic startup.
The time off itself was great. I struggled to get away from needing to feel productive, but did explore some new tech and played some games. I would recommend a small break to anyone.
You would think being in management would make reentry harder, but I got a good pay bump and switched industries. The market is definitely hot. I also didn't get questioned about my time off. I framed it as "taking care of family" and that was the end of it.
I tell this to my newbies too - make sure you're developing good work habits. If this break is the result of the pandemic, do it. But if you're doing it to get away from work after only a few years of experience, be careful because unsustainable work habits don't go away.
There's a tangent behavior where people are difficult because it gives them power/control. You add just enough interpersonal friction and people will do it your way. It's similar to the described scenario - nothing is good enough and there's always a justification.
I've found it an incredibly hard behavior to manage with no good outcomes. People acting in good faith just need to align on the allowed variance and the issue's done.
I'll add here, even if it's not really what you're looking for. I'm a director, not at faang, fwiw.
My first 2 years of managing was hands on, probably 50% coding. I had a small scope and the energy to do people things while also doing coding things. What I found was that this doesn't scale and that if I ever wanted to lead larger initiatives and have a bigger impact, I'd need to give up coding. During this period, I burnt out trying to grow both technically and managerially. The context switching required of me was too much.
When I got to a position where I could do people management 100% of the time, it was transformative. In the same way we think about coding - what skills do I need to develop, how can I optimize XYZ, is there a better pattern for this, etc - I now started to think about management. Part of this is that I joined an org that truly valued management and was able to be mentored and allowed to develop my skills.
Now as a director, I insist that my new managers don't code. There is a period of time where you need to focus on management and nothing else. Later on, I don't care if you want to get into the code, but at that point, no one chooses to.
It does seem like the industry is split on where a manager title exists and if you're hands on. Regardless of which way you go, you'll find career growth imo. I would consider if you feel like you're being the best manager you can be though.