7 ms·

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most peo

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.

deleted 4y ago
[deleted]
dt3ft 4y ago
We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.
- dubswithus 4y ago
  What happens if you do it anyway and don't put it on the board?
  - bendbro 4y ago
    You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.
    - dubswithus 4y ago
      I'm not trying to get a higher salary or promotion. I make enough money. I can't say for certain since it has never happened but I would probably quit on the spot if PIP'd.
  - tut-urut-utut 4y ago
    Why would you do that? Worst case, you get criticized for doing unauthorized work. Best case, you spend your time on a task that gets unnoticed, and now you have to do overtime to do stuff that you are assigned to and actually supposed to do.
    - dubswithus 4y ago
      I don't mind criticism. I've been chewed out before. I refuse to work overtime and if push comes to shove I'll find a new job. Why would I do it? Bit of a rebel I guess.
  - voxic11 4y ago
    In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.
    - nso 4y ago
      This made me laugh out loud because it was so unexpected but also makes perfect sense.
    - Chris2048 4y ago
      In the unlikely event that such a repo gets deployed to prod without any oversight?
    - dfsegoat 4y ago
      Ouch. Out of curiosity, are those local or federal regulations?
      - voxic11 4y ago
        Mostly state level here in the US. The feds just don't allow any type of gambling across state lines but otherwise leave it up to the states to regulate. Its actually a huge pain in the ass to deal with since there has been very little standardization of state regulations so far.
- rootusrootus 4y ago
  That definitely sounds broken. I have a hard rule with my PO: 30% of the sprint is mine (read: the team's). He only gets to schedule 70% of the stories according to his priorities. I use that 30% for tech debt, primarily, but sometimes for spike projects and other things that interest us.
  - Guid_NewGuid 4y ago
    It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets. I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again. Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.
    - teucris 4y ago
      As a product manager I appreciate this take. Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. It’s a huge time suck for PM and engineering, but I don’t know if this is avoidable. Maybe more automated verification systems?
      - solatic 4y ago
        > Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. Read the underlying compliance requirements carefully. In the case of e.g. SOC2, the regulation requires visibility but does not say who may open tickets or who needs to approve them. You can do a lot by making processes more open, and so long as they are still visible, you can still pass. If specific customers tell you how to run your business, either write process that isolates their requirements to a bare corner of the business (e.g. a completely separate environment for FedRAMP) or consider firing those customers.
    - sirsinsalot 4y ago
      I fundamentally disagree with this. In our product, a change has the potential to cost businesses lots of money and also bring our customers into legal trouble, potentially making us liable too. That's why we have heavy-handed change control, code vetting and so on. Yes it makes things slower, but due to the risks involved. I've also worked on embedded projects where field updates are HARD and costly. We had heavy-handed change control then. When I put those controls/processes in place, it wasn't due to low confidence, it was due to confidence in two things: (a) even the best SWE makes mistakes and (b) work to control change risk pays off Sure, it isn't appropriate in many chases, but to write-off process as being designed by "low-confidence managers" because you don't see the point, is a bit myopic. Any SWE who thinks that a codebase doesn't benefit from review before merging is driving on ego.
- fmakunbound 4y ago
  > We can’t even push to a git repo unless it has a linked work item/story/task/bug Exactly the same where I work. The pace of getting things done is absolutely glacial compared to what you know you could achieve if you had any agency. I think the only reason this organization I'm temporarily a part of can even compete is that all its competitors must be equally inefficient.
  - sirsinsalot 4y ago
    But when something major breaks, and the answer to the question of "why?" is ... "well, I just thought i'd make that change, but nobody asked for it" what happens then? I wouldn't want to be accountable in that situation. Every change carries risk.
    - Frost1x 4y ago
      And what if the same major thing breaks but you were asked to do it? Your necks on the line and you did something wrong that you were asked to do correctly. The problem is that part of current micromanagement environments isn't just about micromanagement but also passing down risk and responsibility to developers. You can do the change work in a feature branch and propose the idea after the fact. If there's interest "I've already done it." Stakeholders get a bit of instant gratification like their request just materialized into thin air. If they're not interested, don't mention it and let the work go unused, rack it up as professional development time and work. I do this fairly often. If a decision has a bunch of real risk associated with it I make sure to get sign off and create an appropriate evidence trail to pass risk back up when it's passed down. Much of work is just passing risk and liability around to PYA.
      - sirsinsalot 4y ago
        Because if you're asked to do something, someone has presumably thought it through and accepted the risk to the business/client. I'm not sure I'd keep someone on the team who did a branch AWOL and proposed the idea after the fact. Doesn't show much respect for the team, that time could've been spent working towards goals agreed by the whole team. If you don't have a lead or management environment with ears open to exploratory change, tech debt payoff or "do it better" tasks or whatever... and you have to manage up so much... that sounds like an issue to me.
- Chio 4y ago
  I don't believe this is how it is actually implemented in _most_ companies. Where I work every PR must have a linked story / bug / etc but anyone has the rights to create a story so it acts more as a way to track what changes actually goes into a release for x-teams to review and see if they need to document it, etc. In regard to refactors, people tend to just squash them into another change they are making. This makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.
  - throwaway2037 4y ago
    You wrote: <<I don't believe this is how it is actually implemented in _most_ companies.>> I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency. For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture! Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?
- sirsinsalot 4y ago
  I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ... But the actual ticketing/PR system? Change requires control. The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager. A big red flag for me is any org that doesn't recognise and service technical debt and empower engineers to make a win. I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?
  - michaelt 4y ago
    > Change requires control. But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation. In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.
    - sirsinsalot 4y ago
      I'm not sure that's a like-for-like comparison and if those things overlap like that, it sounds wrong: - Ticket: Description of the requirement - Code: How it was done - Review: Peer-learning, change evolution - Unit test: Testing of implementation as understood by SWE - QA: Did the change match the requirement, did the SWE understand it? Is the outcome the right one? Each "item" should serve a distinct purpose, have distinct value and be justified. If they seem like duplicates, then that probably points at issues elsewhere.
      - michaelt 4y ago
        - Ticket: AB-123 Increase the API maximum page size from 500 to 1000 - Code change: MAXIMUM_PAGE_SIZE -500 +1000 - Unit test: assert len(request[0:2000]) == 1000 - Commit message: Increase the API maximum page size from 500 to 1000 - Merge request: Increase the API maximum page size from 500 to 1000. For AB-123 - Daily scrum update: I've increased the API maximum page size from 500 to 1000, if someone could have a look at my merge request. - Deployment request: Increase the API maximum page size from 500 to 1000, for AB-123 - Post-deployment test plan: AB-123, ensure maximum API page size is now 1000 - Stakeholder demo: When an API request is made, the page size is now 1000.
- singlow 4y ago
  Requiring it to be documented and approved is just responsible from a change-management perspective. At my company we have similar requirements and it is basically required to do that in order to meet security audit expecations. The problem is when they managers don't let you have a say in what gets done. If a developer on our team things something should be done and can do it quickly, they are encouraged to create a ticket and do it. It gets code-reviewed and accepted. If it is not a quick change, they need to bring up the ticket at a planning meeting to make sure it is balanced against other priorities.
- onion2k 4y ago
  Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of. If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive. Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.
  - plutonorm 4y ago
    This is like needing to ask to go to the toilet. It's degrading. Utterly disrespectful. You expect people to stick around?
    - onion2k 4y ago
      Updating a dependency, refactoring some code, or just making a 'simple' change sets off a chain of events that affect other people. The other devs need to review the code, the QA team need to test it, and then regression test the rest of the app, the devops team need to deploy it, the legal team need to update the legal documentation that lists the licenses for the dependencies the code has, the technical writers need to change the docs if the update has a visible impact for users, and so on, all across your org. What looks like a small change to a developer is never actually a small change. I really hope there aren't that many people impacted when you go for a piss.
      - plutonorm 4y ago
        Once you have technical decisions being taken by non technical managers you are sunk. It's hugely insulting to experienced engineers and it's a major reason that people leave. People crave respect and if they perceive that they aren't getting it, they will do what they can to get out. You cannot micromanage engineers in this fashion and expect to have good retention.
adrianN 4y ago
Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.
- bruce343434 4y ago
  So you'd rather have bugged out people which decreases morale which decreases productivity? See it as an investment. Yes, motor oil is more expensive than no motor oil, but it makes the engine run a lot better.
  - grvdrm 4y ago
    You're both right, unfortunately - which makes it hard to ever consistently choose a path. Many people are stuck in the middle of the two sides in lots of orgs. Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable. To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received. Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.
  - treis 4y ago
    I see this a lot at my current job. The tech stack is ridiculously complicated and I think a lot of it is due to this sort of motivation. They let developers run wild and build using whatever tools or new hotness that they wanted. But ultimately we sell Widgets. And the 3rd refactoring of an application to use some immutable data library doesn't do anything to help us sell more Widgets. So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".
wes-k 4y ago
I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase. One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.
- dgb23 4y ago
  How does a junior become a senior? By trying stuff that cannot do well yet and making mistakes.
  - eropple 4y ago
    This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best. Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.
    - mwcampbell 4y ago
      Where do you think your understanding went wrong initially? You said you realized that doing anything in the old system was slow. Was it not actually slow? Was the slowness not relevant because there weren't actually that many routes? Were your coworkers resigned to having some minimum level of tedium in web development? Or something else?
mattgreenrocks 4y ago
> If you remove people from the grind for 1-2 days a week The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels. So I respond by easing up on advancing my career, because it gives back to me the least.
- shagie 4y ago
  > The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. There's a book to hunt up... Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency It's written by Tom DeMarco of Peopleware fame.
- Frost1x 4y ago
  Pretty much. I often wonder where people find positions claimed on the internet where they're working 2-3 hours a day. I've increasingly throughout my career saw more and more slack evaporate to a point it's almost nonexistent. I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work. I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels. If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.
commandlinefan 4y ago
> has to be planned and approved It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this: 1. Management demands that every bit of work be associated with a ticket 2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system 3. management complains about devs opening "their own" tickets and prohibits self-opened tickets 4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board) 1. management demands that every bit of work be associated with a ticket...
- sobren 4y ago
  It feels bad too have a ton of structure, but the opposite is worse IMO. Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them." It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.
  - goodpoint 4y ago
    You just gave a bunch of examples of problems that are in no way fixed by ticket bureaucracy, only hidden.
    - namaria 4y ago
      A lot of this thread boils down to "bad engineering is bad" and "bad management is bad". Not a lot of insight to be found IMO...
- 4y ago
mysterydip 4y ago
> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.
heretogetout 4y ago
We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more. And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev. * the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.
- politician 4y ago
  I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.
kilroy123 4y ago
I could not agree more. My current gig is the opposite and after a year I'm ready to leave.
_yasmeen 4y ago
That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!" This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.
Chris2048 4y ago
> Everything has to have some immediate business impact. Or more specifically, explainable business impact. But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.

deleted 4y ago

[deleted]

dt3ft 4y ago

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

dubswithus 4y ago
What happens if you do it anyway and don't put it on the board?
- bendbro 4y ago
  You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.
  - dubswithus 4y ago
    I'm not trying to get a higher salary or promotion. I make enough money. I can't say for certain since it has never happened but I would probably quit on the spot if PIP'd.
- tut-urut-utut 4y ago
  Why would you do that? Worst case, you get criticized for doing unauthorized work. Best case, you spend your time on a task that gets unnoticed, and now you have to do overtime to do stuff that you are assigned to and actually supposed to do.
  - dubswithus 4y ago
    I don't mind criticism. I've been chewed out before. I refuse to work overtime and if push comes to shove I'll find a new job. Why would I do it? Bit of a rebel I guess.
- voxic11 4y ago
  In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.
  - nso 4y ago
    This made me laugh out loud because it was so unexpected but also makes perfect sense.
  - Chris2048 4y ago
    In the unlikely event that such a repo gets deployed to prod without any oversight?
  - dfsegoat 4y ago
    Ouch. Out of curiosity, are those local or federal regulations?
    - voxic11 4y ago
      Mostly state level here in the US. The feds just don't allow any type of gambling across state lines but otherwise leave it up to the states to regulate. Its actually a huge pain in the ass to deal with since there has been very little standardization of state regulations so far.
rootusrootus 4y ago
That definitely sounds broken. I have a hard rule with my PO: 30% of the sprint is mine (read: the team's). He only gets to schedule 70% of the stories according to his priorities. I use that 30% for tech debt, primarily, but sometimes for spike projects and other things that interest us.
- Guid_NewGuid 4y ago
  It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets. I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again. Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.
  - teucris 4y ago
    As a product manager I appreciate this take. Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. It’s a huge time suck for PM and engineering, but I don’t know if this is avoidable. Maybe more automated verification systems?
    - solatic 4y ago
      > Lots of bureaucracy is caused by a few base requirements for compliance/governance required by laws or customer need. Read the underlying compliance requirements carefully. In the case of e.g. SOC2, the regulation requires visibility but does not say who may open tickets or who needs to approve them. You can do a lot by making processes more open, and so long as they are still visible, you can still pass. If specific customers tell you how to run your business, either write process that isolates their requirements to a bare corner of the business (e.g. a completely separate environment for FedRAMP) or consider firing those customers.
  - sirsinsalot 4y ago
    I fundamentally disagree with this. In our product, a change has the potential to cost businesses lots of money and also bring our customers into legal trouble, potentially making us liable too. That's why we have heavy-handed change control, code vetting and so on. Yes it makes things slower, but due to the risks involved. I've also worked on embedded projects where field updates are HARD and costly. We had heavy-handed change control then. When I put those controls/processes in place, it wasn't due to low confidence, it was due to confidence in two things: (a) even the best SWE makes mistakes and (b) work to control change risk pays off Sure, it isn't appropriate in many chases, but to write-off process as being designed by "low-confidence managers" because you don't see the point, is a bit myopic. Any SWE who thinks that a codebase doesn't benefit from review before merging is driving on ego.
fmakunbound 4y ago
> We can’t even push to a git repo unless it has a linked work item/story/task/bug Exactly the same where I work. The pace of getting things done is absolutely glacial compared to what you know you could achieve if you had any agency. I think the only reason this organization I'm temporarily a part of can even compete is that all its competitors must be equally inefficient.
- sirsinsalot 4y ago
  But when something major breaks, and the answer to the question of "why?" is ... "well, I just thought i'd make that change, but nobody asked for it" what happens then? I wouldn't want to be accountable in that situation. Every change carries risk.
  - Frost1x 4y ago
    And what if the same major thing breaks but you were asked to do it? Your necks on the line and you did something wrong that you were asked to do correctly. The problem is that part of current micromanagement environments isn't just about micromanagement but also passing down risk and responsibility to developers. You can do the change work in a feature branch and propose the idea after the fact. If there's interest "I've already done it." Stakeholders get a bit of instant gratification like their request just materialized into thin air. If they're not interested, don't mention it and let the work go unused, rack it up as professional development time and work. I do this fairly often. If a decision has a bunch of real risk associated with it I make sure to get sign off and create an appropriate evidence trail to pass risk back up when it's passed down. Much of work is just passing risk and liability around to PYA.
    - sirsinsalot 4y ago
      Because if you're asked to do something, someone has presumably thought it through and accepted the risk to the business/client. I'm not sure I'd keep someone on the team who did a branch AWOL and proposed the idea after the fact. Doesn't show much respect for the team, that time could've been spent working towards goals agreed by the whole team. If you don't have a lead or management environment with ears open to exploratory change, tech debt payoff or "do it better" tasks or whatever... and you have to manage up so much... that sounds like an issue to me.
Chio 4y ago
I don't believe this is how it is actually implemented in _most_ companies. Where I work every PR must have a linked story / bug / etc but anyone has the rights to create a story so it acts more as a way to track what changes actually goes into a release for x-teams to review and see if they need to document it, etc. In regard to refactors, people tend to just squash them into another change they are making. This makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.
- throwaway2037 4y ago
  You wrote: <<I don't believe this is how it is actually implemented in _most_ companies.>> I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency. For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture! Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?
sirsinsalot 4y ago
I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ... But the actual ticketing/PR system? Change requires control. The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager. A big red flag for me is any org that doesn't recognise and service technical debt and empower engineers to make a win. I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?
- michaelt 4y ago
  > Change requires control. But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation. In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.
  - sirsinsalot 4y ago
    I'm not sure that's a like-for-like comparison and if those things overlap like that, it sounds wrong: - Ticket: Description of the requirement - Code: How it was done - Review: Peer-learning, change evolution - Unit test: Testing of implementation as understood by SWE - QA: Did the change match the requirement, did the SWE understand it? Is the outcome the right one? Each "item" should serve a distinct purpose, have distinct value and be justified. If they seem like duplicates, then that probably points at issues elsewhere.
    - michaelt 4y ago
      - Ticket: AB-123 Increase the API maximum page size from 500 to 1000 - Code change: MAXIMUM_PAGE_SIZE -500 +1000 - Unit test: assert len(request[0:2000]) == 1000 - Commit message: Increase the API maximum page size from 500 to 1000 - Merge request: Increase the API maximum page size from 500 to 1000. For AB-123 - Daily scrum update: I've increased the API maximum page size from 500 to 1000, if someone could have a look at my merge request. - Deployment request: Increase the API maximum page size from 500 to 1000, for AB-123 - Post-deployment test plan: AB-123, ensure maximum API page size is now 1000 - Stakeholder demo: When an API request is made, the page size is now 1000.
singlow 4y ago
Requiring it to be documented and approved is just responsible from a change-management perspective. At my company we have similar requirements and it is basically required to do that in order to meet security audit expecations. The problem is when they managers don't let you have a say in what gets done. If a developer on our team things something should be done and can do it quickly, they are encouraged to create a ticket and do it. It gets code-reviewed and accepted. If it is not a quick change, they need to bring up the ticket at a planning meeting to make sure it is balanced against other priorities.
onion2k 4y ago
Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of. If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive. Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.
- plutonorm 4y ago
  This is like needing to ask to go to the toilet. It's degrading. Utterly disrespectful. You expect people to stick around?
  - onion2k 4y ago
    Updating a dependency, refactoring some code, or just making a 'simple' change sets off a chain of events that affect other people. The other devs need to review the code, the QA team need to test it, and then regression test the rest of the app, the devops team need to deploy it, the legal team need to update the legal documentation that lists the licenses for the dependencies the code has, the technical writers need to change the docs if the update has a visible impact for users, and so on, all across your org. What looks like a small change to a developer is never actually a small change. I really hope there aren't that many people impacted when you go for a piss.
    - plutonorm 4y ago
      Once you have technical decisions being taken by non technical managers you are sunk. It's hugely insulting to experienced engineers and it's a major reason that people leave. People crave respect and if they perceive that they aren't getting it, they will do what they can to get out. You cannot micromanage engineers in this fashion and expect to have good retention.

adrianN 4y ago

Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.

bruce343434 4y ago
So you'd rather have bugged out people which decreases morale which decreases productivity? See it as an investment. Yes, motor oil is more expensive than no motor oil, but it makes the engine run a lot better.
- grvdrm 4y ago
  You're both right, unfortunately - which makes it hard to ever consistently choose a path. Many people are stuck in the middle of the two sides in lots of orgs. Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable. To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received. Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.
- treis 4y ago
  I see this a lot at my current job. The tech stack is ridiculously complicated and I think a lot of it is due to this sort of motivation. They let developers run wild and build using whatever tools or new hotness that they wanted. But ultimately we sell Widgets. And the 3rd refactoring of an application to use some immutable data library doesn't do anything to help us sell more Widgets. So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".

wes-k 4y ago

I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt. I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase. One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.

dgb23 4y ago
How does a junior become a senior? By trying stuff that cannot do well yet and making mistakes.
- eropple 4y ago
  This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best. Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.
  - mwcampbell 4y ago
    Where do you think your understanding went wrong initially? You said you realized that doing anything in the old system was slow. Was it not actually slow? Was the slowness not relevant because there weren't actually that many routes? Were your coworkers resigned to having some minimum level of tedium in web development? Or something else?

mattgreenrocks 4y ago

> If you remove people from the grind for 1-2 days a week The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels. So I respond by easing up on advancing my career, because it gives back to me the least.

shagie 4y ago
> The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out. There's a book to hunt up... Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency It's written by Tom DeMarco of Peopleware fame.
Frost1x 4y ago
Pretty much. I often wonder where people find positions claimed on the internet where they're working 2-3 hours a day. I've increasingly throughout my career saw more and more slack evaporate to a point it's almost nonexistent. I always wondered why people complained about how much time certain aspects took up they could automate away and my question was always: well, once you automate away that nice simple task, what do you do with the extra time? You created more slack and someone's going to come looking to fill that void the second they're aware. And the new task is going to be more difficult until you get to sets of tasks so cognitively intense and complex you can't simply automate them away. Then your day is filled with incredibly challenging stressful work. I have no issue with doing complex work, I've spent my career doing it. What I have issue with is the amount of such work I can do in any given time span. At some point I need a break where I do something simple and mundane. Continous complex problem solving is the road to burnout. You'll be greeted by more and more failure and lack of visible progress combined with ever increasing stress levels. If you're an entrepreneur, small business owner, or manager looking to optimize your labor force then you may want the opposite. You want more time to focus on the complex and the more simple you can automate, the better or if you have a workforce, you want your highest comped individuals focusing on the most optimally complex tasks they're capable of handling. You don't want your Fellow level engineer refilling the coffee maker because it's empty or implementing some basic features on some UI, go back to inventing new algorithms, math, or building new technology... but people need those nice relaxing breaks and slack, they can't run at their best constantly.

commandlinefan 4y ago

> has to be planned and approved It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this: 1. Management demands that every bit of work be associated with a ticket 2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system 3. management complains about devs opening "their own" tickets and prohibits self-opened tickets 4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board) 1. management demands that every bit of work be associated with a ticket...

sobren 4y ago
It feels bad too have a ton of structure, but the opposite is worse IMO. Single line tickets from the CEO that turn into months long projects with no guidance on the functionality. Engineers that burn down entire features because "it's bad code." Secret projects where you get berated for asking stakeholders to to clear up requirements because "you're scaring them." It's easy to look at a rigid structure and assume it sprang wholecloth from Zeus's head - but most of the time it's an overcorrection. Being burned by a company where Freedom is just an excuse to make employees to work overtime will make anyone go a little overboard.
- goodpoint 4y ago
  You just gave a bunch of examples of problems that are in no way fixed by ticket bureaucracy, only hidden.
  - namaria 4y ago
    A lot of this thread boils down to "bad engineering is bad" and "bad management is bad". Not a lot of insight to be found IMO...
4y ago

mysterydip 4y ago

> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.

heretogetout 4y ago

We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more. And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev. * the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.

politician 4y ago
I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.

kilroy123 4y ago

I could not agree more. My current gig is the opposite and after a year I'm ready to leave.

_yasmeen 4y ago

That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!" This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.

Chris2048 4y ago

> Everything has to have some immediate business impact. Or more specifically, explainable business impact. But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.