stocktech
Joined 11 years ago
Karma
287
Submissions
135
Member since
Dec 18
Recent submissions
Comment · 6 months ago
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.
Comment · 7 months ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
iirc, eqemu reverse engineered the server based on the traffic. I remember being impressed.
Comment · 3 years ago
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?"
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
A junior dev isn't competing with those people. Teams don't only hire senior+. SWE is still a fine career.
Comment · 3 years ago
my self?
Comment · 3 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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.