10 ms·

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overw

• pif 4y ago
  > I'd love to work with a dev who's happy to think about how to most quickly deliver value I'd love to work with a PM who has the courage to engage over a detailed specification document.
• xupybd 4y ago
  I've been there, so far away from the business use of the product that my solutions focused on the tech. I'm sorry. Now I'm right on the front lines of the business and it's eye opening. I think we need to take time to tech the domain to devs first. It's expensive and won't pay off unless the dev stays on the project for a while but it's the only way to allow the dev to understand what they're trying to do for the business. In reflection I'm wondering if the problem is more that an external consultant is often not aligned with the business. Being directly employed helps with alignment.
  • charlie0 4y ago
    The problem is that most companies don't proactively teach the business side to the devs, I know mine doesn't.
• TideAd 4y ago
  Do you understand the basic reasons why? Developers are on the hook for bad code and complexity. Rushed code makes feature work take longer, it makes working more irritating, and creates operational work. Everyone is burned by a team that does these things poorly at some point in their career and it drains the life out of you. They need to trust that you'll schedule time to go back and do things correctly. Clean up technical debt, nail down all the requirements, etc.; you don't want to be jumping from MVP to MVP. Maybe you do this well, I don't know. But you need to understand the motivations and incentives of the devs you work with better or you're going to be fighting them constantly.
  • ornornor 4y ago
    You nailed it.
  • devmunchies 4y ago
    > Rushed code makes feature work take longer grug say nothing of "rushed code". Grug get sick if grug drinks from dirty water, even if it is closer than walking to clean water. Rushed code and dirty water hurts Grug. But that not mean that Grug needs to dig a trench to clean water, or build wall like beaver to get more clean water, it hurts Grug's back. Grug just walk to clean water when Grug is thirsty. Grug dig canal to clean water before, and Grug need to always keep canal clean and me not able to hunt for food because me digging new holes. One time, chief said village need to move to other side of mountain. Grug said goodbye to canal and my beaver wall. Grug should not built them.
    • deleted 4y ago
      [deleted]
  • verve_rat 4y ago
    100% A bad code base is a mental health hazard, and that shit hurts. Of course time crunch isn't the only thing that makes a bad code base. Devs bike shedding to much, or just not being good at maintaining a code base can have the same effect, but not having the time to protect your own future mental health really starts to weigh on a workplace.
• deleted 4y ago
  [deleted]
• goodoldneon 4y ago
  It's a balance. As an engineer, I'm constantly dealing with the consequences of a "the feature worked so we shipped" mindset. Churning out features without thinking about architecture creates increasing amounts of code "tangle" that gradually slows down feature dev. On the flip side, thinking too much about architecture slows down feature dev
• galaxyLogic 4y ago
  You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the product at all. I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for the whole system when you know what needs to be there and what it needs to do. Code-quality is important no doubt, but it is not important for code that doesn't end up in the final product.
  • mecha_ghidorah 4y ago
    I definitely think prototyping should be more common but the problem is I've been burned before. "Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project" Then "Oh hey we are going to give that proof-of-concept project to a client to try out and give us feed back. Don't worry they know it's just demo code at this point".... Shortly after that though it's "The client wants these changes and you're who has to support it now. The client says it's slow, why is it slow? Client wants a new feature, add a new feature!" And I'm left dealing with a horrid, awful, garbage piece of code because I'm the one that wrote it. I was explicitly told to write it entirely as a proof of concept and not as anything production ready which is why it's shit. This has happened to me more than once. So until I have my PMs and Team lead tell me a thing is going to be a prototype/PoC and it turns out to actually be one at least once at this point I assume it's a lie
    • NateEag 4y ago
      The key to having prototypes and PoCs work out okay is to leave some important piece of UX out entirely. Such an approach gets you the benefits of being able to explore a problem space with code in a quick, sloppy manner, without any risk of anyone actually deploying what you wrote.
      • eurasiantiger 4y ago
• lmarcos 4y ago
  That's because such developers know that they won't have to maintain such code. They will probably be gone (switch to another company) in 1 or 2 years.
  • SamBam 4y ago
    I think you have it backward. I'd much rather maintain pristine, clear, well-architected code than code that was shipped to a deadline, if I had a choice.
    • rob74 4y ago
      Well, there is always a deadline, isn't there? I mean, not many of us have the luxury to say, "I'll just work on my pristine, clear, well-architected code and it will be done when it's done" (except maybe in side projects)...
      • Chris2048 4y ago
        You can still have a deadline, just one adjusted for how long something will take if done right (aka estimate) vs how soon they want it.
• zero_shift 4y ago
  It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if they can harangue developers into overtime, out-of-hours alerts or death marches. It’s asymmetric risk. Don't take that personally. I’m sure you, individually, do the right thing. But my experience is that PMs / POs / team leads as a group can be bad actors. It's just the way incentives are structured for middle managers. By the time the problems of your "pragmatic" architecture have emerged, your typical PM / EM / team lead will either be working on another team, doing another job, or talking about "tech debt" as "just one of these things", a mysterious natural force, visiting your team stochastically like a freak summer snowstorm or an outbreak of measles. _That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"? Experienced developers do, which is why we've learned the best strategy in the long run is to avoid offering too many concessions to people without skin in the game.
  • lukasb 4y ago
    I'm sorry that you've apparently only worked with bad PMs.
    • zero_shift 4y ago
      Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful. Some of the best work of my career has been when I've gone off piste and prototyped something that has surprised my managers or disrupted the way a team thought they had to work. You can't go rogue often, and you have to expend your political capital carefully. But you will never do the best work of your career waiting for someone to assign you it in JIRA.
• riazrizvi 4y ago
  The difference is mostly a result of perspective, that could be fixed. The PM has the use cases and product gestalt, if this was shared and made the environment in which the devs work, their prioritizing shifts to product, and engineering concerns would be limited to more obvious ones that make sense. But it’s human nature to protect one’s job and decision making autonomy. PMs being no exception, often underweight their roles in communication transfer and overweight them in decision taking.
• jeffparsons 4y ago
  I think I have a near-pathological experience of coding these days that just so happens to make me the exact kind of developer you want: 1. I still want to produce excellent code that will deliver value, work predictably, be fast, and be robust against future grugs. I am driven to do this by forces I don't understand myself. 2. I also feel a deep dread of being stuck with a piece of code for any longer than absolutely necessary lest I end up trapped in it forever, so I want to be rid of this code and be rid of it now, which means I need to find a way to get it done and ship it so I can move on to the next urgent thing. The result is that you will get a steady stream of good code from me with pragmatic and well-documented compromises, for the low, low cost of my sanity.
  • eurasiantiger 4y ago
    Imagine going to a master craftsperson, and telling them you want them to give you the 80% experience for 20% of the price. How to do that without being disrespectful? How come programmers accept this kind of disrespect for their craft? Aren’t they supposed to be the masters, the Hattori Hanzos of program code?
    • deleted 4y ago
      [deleted]
    • achenet 4y ago
      Martin Guitars has a range of guitars ranging from ~$1500 to $10,000 in price. The sound and play-ability on all of them is superb, what differentiates them is the materials and the aesthetic aspects - i.e. fancy inlays and stuff. Similarly, I imagine you could go see a stone mason and ask for a simple brick wall for 20% the price of an ornate bas-relief facade, which would still be well constructed. Or ask a blacksmith for a simple sword, rather than one with all sorts of shiny metalwork on the hilt.
      • eurasiantiger 4y ago
        Does the corporate luthier fancy working on the simple stuff, or the complex stuff? Neither, because they likely work a single phase of an assembly line instead of finishing an instrument all by themselves. This is where the Martin Guitars analogy breaks down: the guitars are not bespoke products. Pieces of computer software obviously are, otherwise we wouldn’t be having this discussion. Look at any entrepreneur luthier, however, and the story is very different. All their instruments are unique, and they may work on some complex ones for a long time before they decide it is ”good enough” for their standards of quality. In the same sense, independent masons and smiths are, of course, more aligned with software engineering than any of their corporate counterparts—if any, because these professions are rather contracting-oriented. Maybe seeing complexity as inherently problematic is actually a coping strategy employed by software craftspersons who have struggled with corporate demands such as inhuman work allocation and deadlines, internalised those demands as ”the way business OUGHT TO be done” (as if expecting a punishment for doing otherwise), and eventually become grugs who shake their club at anyone who triggers their corporate PTSD. I really hope the grug meme does not become reality.
• bigiain 4y ago
  > Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes. I've worked with my share of them, but I've also worked with my share orders who'll hack together the quickest possible kludge that meets enough of the requirements to seem to work on the surface. Interestingly, given the choice, I'd have some of both those types on my team. I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation. I also really like having "that guy" who can hack minified javascript and manually deploy it on prod servers to fix a critical bug _right now_ while someone else goes through the "proper process" to get it into the repo and through the CICD... But you really really need a majority of your dev team who'll take the proper pragmatic approach, or at least who can be cajoled into doing so.
  • collyw 4y ago
    > I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation. I would argue the opposite, having inherited a complete shambles. Started when Mongo was peak hype, but would be far better suited to a relational database. Lots of developer time spent to run on Kubernetes, so we can scale, even though we are in no danger of a having high volume of customers in the forseeable future (it's a very specialized domain).
• randompi 4y ago
  > In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. In practice tho, the grass is always greener on the other side. You either wish the developer had just hacked something to get it going, when the feature failed, or you wished they had put more effort to make it more abstract and scalable, when the feature set for scaling. Everyone's a genius on hindsight. Getting it right is more of a mix of experience, gut feel and luck imo.
• majormajor 4y ago
  How are you hiring your devs? The more abstract-problem/algorithmic the hiring process, the more I see this. Ask practical coding problems instead, screen for practical devs who can find 80/20 style shortcuts. (You probably still want some of the abstract folks too, though, to round things out.)
• Trasmatta 4y ago
  Do you have enough of an understanding of the codebase to know what is over engineering and what isn't? If not, that's the problem I have with a lot of project managers. If you can't understand the codebase, how can you make judgment calls like that? It can be very hard to make the right call between over and under engineered, even if you're intimately familiar with the codebase.
• BobbyJo 4y ago
  PMs represent the customer. That being the case, they push hard for features and leave it to engineers to keep features coming out at predictable speed. Engineers represent themselves. They are accountable for feature delivery speed and product stability. That being the case they push hard for hardening, automating, and maintaining. The two have to balance each other out. PMs need to push to keep Eng focused on growing business value, otherwise the company will never make money. Eng needs to push PMs to focus on long term product delivery, otherwise customers will leave as quickly as they come, and new one's will stop showing up, no matter how pretty the UI looks. If you had a team of engineers like you describe it would only be heaven for about 6 months in my experience. I've seen two separate teams of engineers run this way. Everything was kick-ass until it was suddenly horrible and engineers started bailing.
• IshKebab 4y ago
  Obviously it's a scale but I hope you aren't falling into the trap of only seeing the features. The developers actually have to work in the code so it might not make a difference to you if the feature is implemented cleanly or not (in the short term anyway) but it obviously does to them.