Procrastination is like getting into the pool for the first time in the morning. Gradual exposure to the cold water is the most painful way to go. The fastest way to get going is to jump in!
I totally understand. It sounds like you've been put in a frightening spot. These transitions really hard enough to do for established managers that have worked at a company for a while, let alone for a fresh hire. It sounds to me like you are doing all the right things: putting tasks into systems and managing expectations.
A growing organization is used to moving fast and when you reach a certain size, you start spinning wheels. Very rarely do companies stay ahead of the curve and setup systems before they hit that wall. You are in the unfortunate position of having to slam the breaks.
Often a company needs an outsider influence to be able to do that. The old guard is used to going fast and haven't developed the tools to go far yet. To me, it sounds like you are doing exactly that. Accept that there will be friction. The new company will work for different personalities. The people that take you from 5-50 are going to be completely different that take you from 50-500. You will lose people in this transition and all you can do is keep a steady course and communicate realistic expectations to stakeholders.
Something that helped me a ton during a turbulent time was implementing patrols. Now, I was lucky to be granted a lot of freedom to implement process changes. But it did really help us to minimize all the small tasks and distractions that kept coming up. Regardless of what tools you use, those little in-betweeners are by far the cause of most overhead. They never really take less than an hour to complete and they are constantly taking an engineer out of the working memory for a complicated task. Also, people love doing them, because you get a small accomplishment every few hours. It's much more difficult to sit with a long project for weeks without much progress, but it's easy to pickup low-hanging fruit. You're doing well to eliminate those.
When it comes to a billion client requests, a bit of requirement engineering goes a long way. Go through the requests and try to understand the root of the problem they are trying to solve. Propose a projects around solving that problem and eliminate all the chatter while your team can focus. If the requirements for that project change too much, then that means the chatter is even more wasteful and needs to be eliminated. A smart business will recognize this.
As for expectations. Yeah, it sounds like it's up to you te set expectations for you and your team. Stakeholders don't have preset expectations and often look at you to set the standard. You want to bring clarity to the table. You want to have the difficult conversation about responsibility and accountability. Again, none of that has much to do with databases and virtual machines.
I'm sorry, I think ik misinterpreted. To me it sounds liken you could accomplish it with the evaluate expression context in the debugger
Come over to the wonderful world of [email protected]. Us dotnet nerds really take this kind of stuff for granted...
You either start saying no to unreasonable demands, or you hire someone that will take the heat for saying yes.
Lattice sounds awful. We use 7pace to track time spent on work and prioritise on that data. We don't impose time limitations, just measure reality.
If you can convince your org to let you keep your documentation and processes in git and maybe a static webiste you won't need anything more than markdown and mermaid.
First of all, thank you for sharing all of this. If more people shared difficult management challenges like this, we would all feel a little bit less like imposters.
The situation you describe isn't uncommon. I think most of us have had a stint in a shop or at least a period where we are asked to perform miracles. We are tasked with this with such confidence that it feels like we aren't up to it. This isn't true. The reason we are asked to perform miracles is because technology is miraculous for most people and the difference between an easy and an impossible project is completely opaque.
Now let me be clear. If you are having a bad time at your job, you should leave. Life is too short to stay with places and people of torture if you can afford not to.
But, if you are willing to give it a shot here's my assessment. The story you're sketching sounds like a turbulent time where the business is growing rapidly and/or has lost Engineering leadership. Engineering leadership is needed to to have realistic projects. If your job is to perform miracles, you will fail every time. What you can do is able to communicate realistic limitations to your stakeholders and negotiate consensus on what can be achieved. You need to create a situation where the business can sacrifice a 20% chance of taking 5 steps forward this quarter for a guarantee of taking a single step. A business that can't see the value in that is dead in the water anyway.
The engineers on the other side, need to have their priorities cleared and set. You need to recognise premature optimisation, hobby projects and resume fluff and put an end to them.
This has nothing to do with Amazon lambda and everything to do with communicating arguments effectively, creating relationships of trust with stakeholders and developers.
I won't lie. This role will cause alot of friction, but it sounds like the business has no one to tap on the breaks. In the end the real miracle would be to turn the boat around and have some predictability in the workplace.
It's just transparent. It feels like alot of lessons were learned from the broken abstractions of older ecs engines. It might not be as powerful yet, but the foundation is solid and it's easy to implement the more complicated stuff.
Also, dotnet 6 implementation is a breath of fresh air.
So what we do is, between the first and second interview we have new candidates recreate Twitter over the span of a week. We stress that they can put in as much time into it as you want. By no means does the site need to be functional at all by the second interview. If they spend 30 minutes thinking about it and are able to have a decent conversation, great! 30h assignment is a bit much and a programmer with that kind of time, is a bit of a red flag actually.
The point of the assignment, for me, is not to have some barrier of entry for a candidate. Instead, I use the assignment to:
- Have something to talk about
- See how good they are at structurally dissecting the problem
- Do they get bogged down in details
- In what order do they attack the problem
- Are able to effectively communicate some basic concepts around web-development
- Request sequences
- Authentication
- Database Schemas
- Asses their personality
- Do they want to try some new tech
- Do they polish
- How broad are their technical interests
- Do they do tests, did they host the project, did they do something interesting with UI
- How deep does their knowledge go
- did they use the right tools, do they have experience
- Have room for some hypotheticals
- How would you do it in a team
- what would you do with a month of time
When you look at it like that, the project doesn't really need to be that complicated. A candidate may be able to fake a challenge, but they can't fake an interview.
Access Control
If you really want to make a game then gamedev is for you.
There really isn't any way to start and be good. Your taste will exceed your skills at first. This is a painful period where you will find out if you enjoy the process or the idea of the finished product.
If you can't code or do art, maybe Godot or Unity might be a bit too much. Start out with something like löve some indie classics have been made in it and it's a great way to start learning to code and create simple assets.
Start out recreating simple arcade games. These are so full of teachable moments it's like a cheat code for getting good.
If you can make something with a start screen, a game loop and a game over screen, you've got a game. You're a game dev. Everything else, if you haven't lost your mind yet, will go well.
PS. Please, for the love of god, if you are still in school, pay attention to geometry. If there is anything I could go back in time and do pay attention in math class.
What are some things you're trying to accomplish? C# looks very different in the cloud, as a website, in a game engine or on a mobile app.