High level IC (individual contributors) should have a support group. Managing the transition from being “just another engineer” to being a “force multiplier by working through others” is tough. Talking to others that have managed that transition is calming.
Your role suddenly goes from cranking out lots of code to mentoring/growing others, and shaping the team culture. Often times companies train managers but don’t formally prepare ICs for those roles. Learn on the job, become a great people person!
One of the hardest things is measuring your impact. You don’t have anyone reporting to you, and you are no longer being judge solely on your technical abilities. What did you do at the end of the year? It can feel very abstract at times.
There’s also a lot more meetings somehow. So you don’t have a team, you’re not supposed to be coding really and you got to lots of meetings and give advice? Turns out lending your expertise is hugely impactful and part of the shift is learning how to talk about what you do.
Learning how to talk about parts of the product you influenced without feeling like you’re taking credit for things you didn’t directly touch. It’s hard but it’s part of the role shift.
All that’s said, I still code all the time and I use it like a weapon when I have spare time. It’s also a way for me to have deep discussions with other members on the team about implementation details. It’s not always the best use of my time but it makes me happy 😊
There’s a place for us to exist! Don’t cave to become a people manager (no shade), I’ve been to asked many times.
I nominate @rakyll to start this cross company support group 🙃
The leaders in my division spend time on this and offer mentoring rings (which I participate in) with high level ICs. They are like therapy.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Here's some code that is on the hot path on your application and you want to optimize it. This is what a typical C# developer would write (actually copilot wrote this). It's pretty clear, but suboptimal. How could you go about improving it? #dotnet #csharp
There are lots of allocations here: 1. The string[] splitting up query string parts by & 2. Each key value pair string[] splitting each part by = 3. The List<string> of new results 4. The final string
One more assumption you can make: The instanceId will only occur once or 0 times in the input querystring.
Discrete events masquerading as a workflow should be expressed as such. Consider the following event-based model: #dotnet
The game has 3 events:
- GameStarted
- GameEnded
- OnQuestion
The order of execution should be obvious from the naming...
The application doesn't control the event loop, the event loop will trigger the events at the appropriate time. Storing state across events means understanding the order in which they fire, the thread safety of such events and more (do they fire concurrently? can you block?)
Currently designing how this trivia game will work on multiple servers. I have 3 architectures in mind (Twitter can help me pick one, but I have a preferred one). Both clients are part of the same game. Games are ephemeral and last a maximum of 2 minutes.
Architecture 1 - Using Redis as the game state storage and SignalR backplane.
Architecture 2 - Use Orleans grains as the SignalR backplane and state storage for a game.
It's Friday so time for spicy opinions. Every single sample ASP.NET Core project I see uses CQRS and the mediator pattern or CLEAN architecture. I'm over the over engineering 🙃. #dotnet
I lean very heavily towards YAGNI and readable code with minimal abstractions until needed. I appreciate that every situation is different, but like anything it's hard to appreciate the benefits when the "scale" problem isn't evident.
Blindly applying patterns bugs me ALOT. I don't subscribe to the dogma, I don't write code that way...
Another cool tye feature is networking support between containers and processes on the host. This nginx configuration is referring the process running on the machine by host name "sample" but that application isn't running in a container.
It manages all of the tricky ways to communicate between containers and local machine using (host.docker.internal) etc. This lets you run and debug your processes normally and run what needs to run as containers in your inner loop.
It creates an environment that looks like this behind the scenes.