111–120 of 203 posts
This works until your boss understands software development
If a client wants X or won't sign a contract worth $Y then the tasks to complete X become valuable regardless of their complexity.
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…
Along with: you will never be thanked for getting a garbage project across the line. You will be thanked more for having a small part in a good project than being the hero on a garbage project.
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…
> It matters, I think, not if the task is easy or hard but if management/product view something as easy or hard. That's eye opening, thank you! I've once worked on a "hard" statistical model and all I got from my boss' boss was a "who cares" face. Then he was so happy to see our (to my view) dumb web app, he didn't even realized it was the model behind that app that consumed 80% of my time/energy :/
Whatever one thinks of the techniques recommended in this article, the perils of working on a "easy" but in actuality hard problem are not to be overstated.
The dreaded 3 point story that takes 3 weeks. ...yeah been there.
1. I am usually never behind schedule 2. I look like a hero when I deliver on time
Earlier quoted context omitted.
That is what I believe you believe and I understand where it is coming from. I've managed juniors and I know they make mistakes. That said, if a junior brings up a question like "why does this error for some tests, but not others?" records = some_orm_thing() some_model_ids, other_ids = map(list, zip(*records)) The answer is obvious. Some tests return no records for the ORM thing and that doesn't unpack. If you ask th…
My wording was maybe a little strong, I did try and clarify a bit in another comment below but, I was maybe a little bit unclear and think I might not have fully understood the point you were making. I admit, I did take it as juniors should just shut up, which i admit probably wasn't the most good faith way to interpret it. I agree there's a difference between the kind of question like the one above vs. something lik…
I think my larger point was that smart juniors should seek to get clarification privately after exhausting their own skill, but you're absolutely right that they should raise issues as they come up in a thoughtful way to accelerate the team and their own growth.
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…
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.