stocktech

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.

iirc, eqemu reverse engineered the server based on the traffic. I remember being impressed.

You can always ask the team. Either in a 1-1 or a retro, "What does my role look like for you?" or "What are your expectations of a manager?"

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.

https://github.com/apache/doris Is a great example. Same for it's cousin https://github.com/StarRocks/starrocks that was an early fork of the doris project.

To be fair, these are the only examples I can think of and I only learned of these as I'm standing up new data infra using starrocks.

A junior dev isn't competing with those people. Teams don't only hire senior+. SWE is still a fine career.

my self?

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.

Interesting. Guess I'll have to figure out social media after all. Thanks.

Out of curiosity, how did you find your customers? I'm building out my MVP to scratch my own itch, but have been hesitating putting it in front of others.

I don't think I really understand what you're getting at. What I'm hearing is that the culture is different, but I'm not sure how that fits into product vs project.

It kinda sounds like you're saying that the work isn't organized. That people just jump in and tackle problems as they come up.

levels.fyi has ranges for metro areas and mostly aligns with what I said.

The majority of SWEs are not making 300k+. Can you? Sure, but 80% of people are making 125-200k in average COL areas.

We'd need a lot more info to make a meaningful suggestion, but I'd at least investigate TimescaleDB to see if it fits. The fact it sits on postgres should be attractive to your client.

Do you have a good relationship with your boss? If you do, just talk to him. He's a person and he probably wants to keep you around.

"Hey, I feel like I'm doing a lot, I want to do more, and I'd like to make more money. Can we talk about it?"

Prepare what you feel is a reasonable title/salary and any documentation you can give on that. From what you have written, I'd ask for Lead Engineer and see if you can find a salary range online. You could even suggest that your boss asks the bigger company what their pay range for the title would be. Also, this needs to be a realistic number. Don't look at Google salaries and expect to match.

The worst way to approach it is a "I want X, give it to me". If you want to put more pressure on it, mention the LinkedIn offers you're getting - "Hey, recruiters keep reaching out to me on LinkedIn and the salaries are pretty high. I really want to stay, can we talk?"

The big take away needs to be the value you have brought to the team and will continue to bring.

There's only a few times I've ever straight denied a request like this. 1) We just did raises and they want more, but don't deserve it. 2) They were at the company for <6 months and their current pay was above the median. Especially when your responsibilities have grown, this should be an easy conversation. The hard part will be getting a good number.

Best of luck.

I did self organizing teams at a startup where Engineering grew from 20 to 100. It sounds like the article had the same philosophy, but implemented it differently. We didn't eliminate roles, but the roles became more fluid along with the person that was performing them.

Before, one person would receive and coordinate work among the team - the tech lead. After, we had a rotating roster of people who were interested in solving problems that would act as a tech lead. This was in coordination with our Product org.

metabase looks native.

I had a similar situation a few years ago and had the same feelings. I was a little burnt out and gave the org a ton of work over the years, so I enjoyed the down time doing side projects and gaming. Then after a year or so, I found a new job.

If you're looking to chill for a bit, this is your best opportunity. As long as you're not lying to anyone, I don't think it crosses any ethical boundaries.

I feel like if a company cares about their culture, they won't need an app. There's also expectation setting that culture will change as an org grows, that's inevitable. It's up to the leaders to know what are responsible changes - like slowing down, collaborative decision making, more documentation, and more communication. This doesn't take an app, just experienced leaders.

Having been in growing orgs and having scaled orgs, there's one thing that has separated cultures that scaled vs those that didn't: conscious, repetitive communication of what the culture is. e.g. the culture is defined and referenced in town halls, team meetings, CEO communications, etc. It's the one thing that actually trickles down if you mean it.

Unsuccessful orgs that I've seen had a verbal history of the culture. The CEO/CTO mentioned it once and it's been repeated by others ever since. In one place, one of their core values was collaboration, but because the culture wasn't really defined, each team had their own subculture that there were rough spots when teams needed to work together. In the same place, they had to continually rehash the same thought process for every tool change - this will slow us down vs it will increase quality. In contrast, speed vs quality should be defined in a culture so that those conversations don't need to be repeated.

A seldom discussed point in org growth is investing in the management layer. Managers are de facto leaders and go a long way in reinforcing the culture. Startups promote those that get things done so management isn't always experienced and this can breed problems if undressed for too long. Once you get past hockey-stick growth, the management layer changes, usually because startup skills are different than enterprise skills, but having seen slower growing orgs get better medium-term results, I think startups can do better in this area.

Anyway, I think culture is a function of how we work. It needs to be defined, constantly communicated, and authentic. I don't think you'll capture the same magic if you abstract that into an app.