4 ms·

Related truisms I've come to: * Watch the test fail first. Write a test FooMethod_Should_Do_X. Confirm it fails. If it passes, it means you're testing the w

Related truisms I've come to: * Watch the test fail first. Write a test FooMethod_Should_Do_X. Confirm it fails. If it passes, it means you're testing the wrong thing. Once it fails, make it pass. Once it passes, make it pretty while still passing * The simplest thing you can do is nothing. As a developer, your first job is to talk customers down from that feature request without annoying them too badly. "What bad things happen if the app doesn't do X?", "Explain the business value of X to me. About how much time or money will this save?". * This applies not just in code. In personal interactions, saying nothing or doing nothing is often better than prematurely doing the wrong thing. There is a time to say and do something, but it is usually later than we think and not on social media.

mcdonje 3y ago
Your 2nd point rubs me the wrong way, though it could just be the wording. Depending on the organization, by the time it got to you, there may have already been discussions about scope and business need. Unless you're an SME, your evaluation of what is needed is not better than that of those who are requesting the work. Sure, your knowledge of the effort is better, but that's not the same thing. There's a decent chance you're going to come across as difficult to work with and then you're going to build a solution that doesn't fully meet their needs. I get where you're coming from, but I've spent time on the other side. Requirements take negotiation and collaboration.
- kthejoker2 3y ago
  You can spin the second questions as wanting to understand why this hasn't been done before, and what the current workarounds are. It gives you some sense of the affordances you need and the current value of having done nothing so far. It also helps with prioritization - is it a must, a should, a could, a wish?
- shireboy 3y ago
  To be sure, part of the challenge for me on that one is to ask it while not being a jerk. Yes, it’s a negotiation. Maybe you and I work in different circles, but in my experience people ask for features they don’t need all the time. They have a business problem, ask for what they think is the technical solution, but may not know the technical options available to solve the business problem. They may ask for a 500 page report so they can find a customer that meets x criteria, but really, better search would help them more. I had a customer sink hundred thousands into cryptographic digital signatures. I suggested the “business analyst” and upper management discuss with legal, and indeed in this case a checkbox sufficed instead. As a dev I like to say my job is to translate English into nerd. Non- or semi- technical people should communicate the business problem and then together we’ll work towards the best solution. Sometimes the solution is code.

mcdonje 3y ago

Your 2nd point rubs me the wrong way, though it could just be the wording. Depending on the organization, by the time it got to you, there may have already been discussions about scope and business need. Unless you're an SME, your evaluation of what is needed is not better than that of those who are requesting the work. Sure, your knowledge of the effort is better, but that's not the same thing. There's a decent chance you're going to come across as difficult to work with and then you're going to build a solution that doesn't fully meet their needs. I get where you're coming from, but I've spent time on the other side. Requirements take negotiation and collaboration.

kthejoker2 3y ago
You can spin the second questions as wanting to understand why this hasn't been done before, and what the current workarounds are. It gives you some sense of the affordances you need and the current value of having done nothing so far. It also helps with prioritization - is it a must, a should, a could, a wish?
shireboy 3y ago
To be sure, part of the challenge for me on that one is to ask it while not being a jerk. Yes, it’s a negotiation. Maybe you and I work in different circles, but in my experience people ask for features they don’t need all the time. They have a business problem, ask for what they think is the technical solution, but may not know the technical options available to solve the business problem. They may ask for a 500 page report so they can find a customer that meets x criteria, but really, better search would help them more. I had a customer sink hundred thousands into cryptographic digital signatures. I suggested the “business analyst” and upper management discuss with legal, and indeed in this case a checkbox sufficed instead. As a dev I like to say my job is to translate English into nerd. Non- or semi- technical people should communicate the business problem and then together we’ll work towards the best solution. Sometimes the solution is code.