5 ms·

This happens all the time I've found, particularly in "agile" processes. You are coding away implementing something and realise there is some corner-case or ed

This happens all the time I've found, particularly in "agile" processes. You are coding away implementing something and realise there is some corner-case or edge-condition that was not considered in the original design and/or UX spec. Stuff that only becomes obvious once you are staring at the code you've just written and are thinking "What should we do if this is null?" So you unilaterally implement something to handle that condition. Especially in agile projects with tight deadlines and the idea of continual refactoring etc, rather than block further work on that feature while you wait for the product owner/business analysts/UX team/etc to come up with an answer and get back to you, you check-in your "best guess" implementation and move on, with a TODO or bug left open to revisit it. A lot of the time (maybe 75%+ in my experience) the developer's instinct tends to hang around as the final solution, even if the developer is not an expert in the context of the users of the application they are writing (this is rare in my experience - generally developers are developers, and not likely to coincidentally be experts in the subject area of the application's use cases unless it is some niche areas - e.g. people writing software for surgery robots are probably also unlikely to be expert surgeons too I would imagine? Not impossible, but I'd want people to be an expert in surgery robot programming, or an expert in surgery and not a half-arsed kinda-ok-done-a-bit-before level of skill in either area!!)

lettergram 8y ago
I had an interesting case a few years back... I was supposed to follow the spec exactly. However, in all the UI/UX diagrams myself and team were given, there was no “close window” or “back buttons”. This included things like pop up notifications. I went ahead and implemented it anyway. Then sent them to the design team to ask if I should remove (took under an hour of work). I was later reprimanded for not following the spec, BUT they kept my implementation and design. This is one experience that sticks out because I was reprimanded. However, I’d say every project I’ve been on has been at least 10% of the the final project designed & implemented by engineers on the spot. Beyond UI design decisions engineering can have a major impact on UX. Every single function can make-or-break the experience. That’s why we, as engineers, wield a lot of power.
- Faaak 8y ago
  I would've gone against them: either you reprimand me and we take out the feature, or we keep it and then you thank me.
  - unkulunkulu 8y ago
    Exactly my thinking, totally irresponsible behavior on the part of design team
  - PretzelFisch 8y ago
    At that point it's best to find a new employer. It sounds like there was some weird ego game being played.
- rossenberg79 8y ago
  On small things like this it’s easy to just gaslight people into thinking they told you it was ok. You can just explain it was such a small detail they probably don’t remember you brought it up and they said it was ok. If they say no, just double down and keep insisting and as long as there are no records of your conversations you will win.
  - unkulunkulu 8y ago
    Lol the problem with gaslighting is not that it’s not easier in some contexts but that it is an actual act of aggression
    - blotter_paper 8y ago
      For a more cynical take on why GP's advice is bad, it also breaks down trust in communication. If I catch you trying to gaslight me once I have to run all of your future statements through a more strict truthiness parser in my head, and I'll place less trust in statements you make that are actually true. People who perceive themselves as smarter than the average bear can sometimes believe that they possess the mental prowess to lie without being caught, and this is often true, but the one time it isn't true it can have devastating effects on interpersonal relationships and communication. I don't even judge people negatively for all lies, if you lie about a detail of your personal life while in a work setting there could be totally understandable privacy reasons for that where a non-answer would have a different effect than a hard "no." But if you lie about prior decision making processes, that breaks down trust in the exact domain that we need trust in. It poisons the well, and that isn't worth a little less friction in one specific decision making process.
Sharlin 8y ago
If I was writing surgery robot software I very much would want a surgeon sitting next to me, or at the very least available for a chat on a reasonably short order. Collaboration is a force multiplier. Unavailability of domain knowledge is a major reason why so much domain-specific software sucks.
- pojzon 8y ago
  "Theoretically" agile means that you have an easy access to the customer to help you with decision making and changing requirements. Unfortunately its VERY rare to meet that requirement for agile (multiple reasons). For mission critical projects like the one you mention, I think, company should pay good money even to few surgeons to be available for the devs. Problem often lies in management to understand that..
  - Sharlin 8y ago
    Yep, and that’s one of the reasons I feel I’m pretty much done with programming as a day jon.
- kazinator 8y ago
  I'd want a surgeon who extensively used the previous version of the surgery robot. :)
closeparen 8y ago
I've never had a spec that would thoroughly describe how to handle every case. The ability to understand and interpolate vague business requirements is expected to scale with your level; if you take a "not my job" approach to such decision-making you are perpetually entry-level.
- wdrw 8y ago
  I've often seen the exact opposite of this: entry-level devs being all too happy to 'fill in the gaps' in a spec based on their own (very limited) understanding of the problem domain (not even being fully aware of where the spec ends and their interpretation begins), and more senior people recognizing when they don't actually know the answer and realizing that it's important enough to clarify with the domain expert. Basically Dunning-Kruger effect.
bartimus 8y ago
> agile projects with tight deadlines If you're not deciding on the sensible deadline, you're not self-managing your project, you're not doing agile.

lettergram 8y ago

I had an interesting case a few years back... I was supposed to follow the spec exactly. However, in all the UI/UX diagrams myself and team were given, there was no “close window” or “back buttons”. This included things like pop up notifications. I went ahead and implemented it anyway. Then sent them to the design team to ask if I should remove (took under an hour of work). I was later reprimanded for not following the spec, BUT they kept my implementation and design. This is one experience that sticks out because I was reprimanded. However, I’d say every project I’ve been on has been at least 10% of the the final project designed & implemented by engineers on the spot. Beyond UI design decisions engineering can have a major impact on UX. Every single function can make-or-break the experience. That’s why we, as engineers, wield a lot of power.

Faaak 8y ago
I would've gone against them: either you reprimand me and we take out the feature, or we keep it and then you thank me.
- unkulunkulu 8y ago
  Exactly my thinking, totally irresponsible behavior on the part of design team
- PretzelFisch 8y ago
  At that point it's best to find a new employer. It sounds like there was some weird ego game being played.
rossenberg79 8y ago
On small things like this it’s easy to just gaslight people into thinking they told you it was ok. You can just explain it was such a small detail they probably don’t remember you brought it up and they said it was ok. If they say no, just double down and keep insisting and as long as there are no records of your conversations you will win.
- unkulunkulu 8y ago
  Lol the problem with gaslighting is not that it’s not easier in some contexts but that it is an actual act of aggression
  - blotter_paper 8y ago
    For a more cynical take on why GP's advice is bad, it also breaks down trust in communication. If I catch you trying to gaslight me once I have to run all of your future statements through a more strict truthiness parser in my head, and I'll place less trust in statements you make that are actually true. People who perceive themselves as smarter than the average bear can sometimes believe that they possess the mental prowess to lie without being caught, and this is often true, but the one time it isn't true it can have devastating effects on interpersonal relationships and communication. I don't even judge people negatively for all lies, if you lie about a detail of your personal life while in a work setting there could be totally understandable privacy reasons for that where a non-answer would have a different effect than a hard "no." But if you lie about prior decision making processes, that breaks down trust in the exact domain that we need trust in. It poisons the well, and that isn't worth a little less friction in one specific decision making process.

Sharlin 8y ago

If I was writing surgery robot software I very much would want a surgeon sitting next to me, or at the very least available for a chat on a reasonably short order. Collaboration is a force multiplier. Unavailability of domain knowledge is a major reason why so much domain-specific software sucks.

pojzon 8y ago
"Theoretically" agile means that you have an easy access to the customer to help you with decision making and changing requirements. Unfortunately its VERY rare to meet that requirement for agile (multiple reasons). For mission critical projects like the one you mention, I think, company should pay good money even to few surgeons to be available for the devs. Problem often lies in management to understand that..
- Sharlin 8y ago
  Yep, and that’s one of the reasons I feel I’m pretty much done with programming as a day jon.
kazinator 8y ago
I'd want a surgeon who extensively used the previous version of the surgery robot. :)

closeparen 8y ago

I've never had a spec that would thoroughly describe how to handle every case. The ability to understand and interpolate vague business requirements is expected to scale with your level; if you take a "not my job" approach to such decision-making you are perpetually entry-level.

wdrw 8y ago
I've often seen the exact opposite of this: entry-level devs being all too happy to 'fill in the gaps' in a spec based on their own (very limited) understanding of the problem domain (not even being fully aware of where the spec ends and their interpretation begins), and more senior people recognizing when they don't actually know the answer and realizing that it's important enough to clarify with the domain expert. Basically Dunning-Kruger effect.

bartimus 8y ago

> agile projects with tight deadlines If you're not deciding on the sensible deadline, you're not self-managing your project, you're not doing agile.