Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "prioritization"
-
Everything is "critical priority" all the time. Every new project is the most important project in the entire company. Every request that comes in has to be handled immediately. I have a good manager now who fights back against the deluge of critical work, but for my first year in my job I had a different manager who would bend over backwards to appease everybody, over-promising constantly.
I eventually started asking questions like "Which project are we de-prioritizing to accommodate this?" or "Is X more or less important than Y?" and then I would focus entirely on whichever project he identified as being the most important, and not touch anything else until I was done. Basically forcing him to prioritize our work.
I almost quit over a few of these issues, but I stuck it out and eventually our team came under new management, and now our manager is the one asking those questions instead of me. As she should be. Her favorite response when someone says a task is critical is "How critical? How much money will the company lose per day if this is late?"
Most of the time, the answer is somewhere in the range of "nothing" until a couple months after the deadline. So we set a much later deadline and get the work done right.6 -
When an application has tons of security holes and fixes never make it into sprint prioritization because "they're not new features"4
-
How to waste money as a dev company, 101:
Give people ton of budget for their education to do whatever they want with it with no oversight at all:
1) Devs go to some shitty confs in places across the world that teaches them nothing (new) so they can visit interesting places on company's money
2) Go to a conf where you learn ton of stuff that can be implemented right away
...Then you come back, no time to do stuff properly, just "make it work" (or make it seem like it works), because of deadlines, poor prioritization, new features, bad planning, vague roadmap and poor client management. And the worst of them all, LGTM code reviews.
Few months later, who the fuck wrote this shit? Oh, dude that left? What about this mess? Oh, he's a goner too. What the fuck should this random undocumented chunk of code do?!
Do that a few times and you've got bunch of pissed off clients with a ton of bug reports nobody can solve without wasting 20x the amount of time it would originally take.. LGTM
RIP project.6 -
For skilled mid-career engineers, dynamic programming problems, np-complete bar raisers.
For new engineers, simple questions that can't be taught in school (questions that require business prioritization)
For older engineers, questions they haven't done since college (big-O, writing algorithms from memory)12 -
How I try to stay productive:
I seem to be slightly less distracted if there are other people around me. Probably because I have to make an effort to focus, which stops a part of me secretly searching for distractions when there are parts of work that I would rather avoid (like googling error messages). So I used to spend some time of the day in a café or in our family kitchen.
Taking breaks an going for a walk, preferably in the forest (when I work from home).
Prioritization of tasks also helps to focus and do one thing after the other. That said, sometimes it inspires me to do more than one task at a time.
Writing down what I did and want to do (in an actual note book on paper) helps me start a new work day, especially after a weekend off. -
My team is pretty small right now. It's myself and two other guys. One lead, who's been here for five years. A senior who we brought on 2 weeks ago. And me, a regular app dev. The lead put his two weeks in last week and has been trying to brain dump as much as he can onto us.
I've been building a list of prioritization to compensate for when he leaves based on what he was saying was the most important. This list has gotten pretty massive after reviewing most of the processes in place.
I was hired mainly to quell new requests coming in and not to maintain our systems, so that's what I did. I didn't examine our prod code base too closely. I wish I had. It's in a sorry state. I'm pretty sure I have about 2 years of tech debt for a crew of two guys constantly working on it.
I've been trying to prioritize based on what gets the most bug fixes and change requests. These apps will see the biggest changes and will undergo the most maintenance.
Since I'm just a regular app dev it feels weird trying to come up with this and try to prioritize this and come up with a plan. It feels like someone else should have. If it needs done then I guess it needs done. I need to be able to collaborate and work with my co worker and be able to plan for what projects are coming next.
If anyone has any suggestions to tackle tech debt please make them. Or if there's any help for managing priorities in a different manner that may prove helpful I'm open. Honestly, I don't want to tackle this completely blind, it feels like a lot.1