Since I started working as a “consultant”, I started using the exact same Evildoer tricks ! I’ve said “No” to partners coming with easy & urgent requests, just because I wasn’t feeling like dropping my work and doing these. To the juniors’ disbelief, I _gained_ their respect. This is also how I never got caught with the “can you stay all night/all weekend and try to get this done before monday ? Our boss just asked f…
I imagine this works as long as you can say no, requiring good financial management and marketing skills. Easy to say no when you are turning away work.
At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and…
> if management/product view something as easy or hard. This applies not just to work done, but work to be done. Once the business people asked me to do something that turned out to be extraordinarily difficult. Afterwards we were talking about it and they mentioned that they considered asking me to do it a different way that would have achieved the same goal, but they thought the second option would be harder, so th…
I think this is a perfect example of why it is necessary to effectively communicate the relative tradeoffs and costs of option A and B when someone asks you to do something.
And to also also questions to dig into what they are really trying to accomplish, and why they are trying to do it that way.
I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud o…
Sounds like you need to be more picky, to get the jobs that genuinely require that level of engineering. I’d find it hollow to add all that complexity when not needed.
"If you do too much people get dependent on you. And if you do nothing, they lose hope…when you do things right, people won’t be sure you’ve done anything at all.”
I will say as someone who has to wrangle a lot of junior devs -- don't have imposter syndrome on this. The hard part is sticking with the issue and seeing it through to the logical conclusion. Many people have difficulty even conceptualizing the steps that need to be taken in order to solve a problem. If you are smart enough to get help from someone in devops and understand the advice they gave, you're doing the same…
I'm a senior dev I say this only because I have to. The problem with encouraging developers to speak up when they're stuck is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard. In some sense senior developers have a real leg up here because they know that they're capable of building systems for…
IMHO the rule of thumb is - no stupid questions, if repeated refer to previous answer, if repeated consider firing an idiot, if it came from above you - consider promotion or giving a notice.
I actively try to avoid to do anything the easy way, because I know ill get bored if do. Motivation is the most valuable resource in programming. I rather do something over engineered that I find interesting, then something simple and boring. Even if it takes 3 times the effort, I know ill put more than 3 times the effort in if I'm motivated, and ill end up learning something and ill end up with something I'm proud o…
Sounds like you’ll end up with something 3x as hard for future engineers to maintain also.
Why? You were given no suggestion in which dimenension the complexity was introduced in. Frequently, the better design requires the additional effort.
Its the quick hacks and shortcuts that accumulate debt fastest.
It's sort of like how it's better to be a firefighter than a maintainer, which is guess is the point. The ease may be similar, but coming in to save everyone from an explosion gets you more points than oiling the valve every day so pressure doesn't build up in the first place. It's a cultural issue that is very hard to combat.
Reminds me of moments I had early in my career where I was the hero for fixing problems I caused. :) That company didn't have code reviews and my bosses weren't very technical, so it was pretty easy to pretend like I wasn't at fault for anything. Sometimes they'd figure out that I caused the problems and even then it didn't seem to really matter. If I had the skills I have now 7 years later, my bosses would probably…
Recently one of my clients noticed something we had broken on their website. When they noticed it, we fixed it in a matter of minutes. They were so pumped on the response time they then left us a very glowing public review.
At my last job I made a feature to deploy arbitrary user code (most likely a trained model in Python) to a subdomain running a JS server that could take input parameters when called at that URL and would respond with the answer from the model. This effectively cut down DS deployments from potentially days to about 45 seconds. It was seen that be hard and I had a good amount of help from our awesome devops person and…
In the last 5 years I have probably written 100k+ lines of production code. My most celebrated feature was about 100 lines to store a single flag in a per user store.
Way to describe the engineer/business disconnect.
You are proud of the complex problems which you have solved over the years. The business is proud of the little widget that made everyone's jobs a bit easier.
I've seen people take this lesson to heart and go full Wally.
Ouch. This hits close to home. I _constantly_ get passed over for the interesting work, despite being _extremely_ qualified for it. (e.g. I keep getting told I don't "have a scientific background", so I'm not qualified to work on problem X, despite the fact that I have a PhD in the field and extensive experience on closely related problems) It's because I'm seen as a technician, not an engineer or a scientist. That's…
I've been the 'fixer' in so many situations and I have a tactic for this. I ask them for the following things: - a ticket to track the work - that they get approval from my manager to drop all of the work that I am currently doing and affect other peoples timelines - that they document the problem and how they want it fixed - that they get approval for the extra hours required You'd be amazed at how many "critical" i…