4 ms·

Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you tim

by m3kw9 3y ago

Sometimes software engineers forget coding should be the final step, and not the main step. Defining as much as you can,80/20 before starting will save you time. Certainly there are cases where you have an idea and you dive right in and it will work out but usually that won’t work out well from my experience

liamN 3y ago
For me, as a rookie developer, I find I often have little to no clue what needs to be done until I've started coding and figured out through trial and error how to implement it and what the requirements even should have been up front.
- jon-wood 3y ago
  Just because I feel more people should hear this early in their career, that’s perfectly normal. I fairly routinely answer questions about how long a piece of work is going to take by saying I’m going to need n days to work out what needs to be done, after which I’ll be able to give an estimate. That sort of exploratory work is really good because you’ll end up reading relevant documentation, then actually trying to use whatever it is you’re learning about. Often I’ll throw together a hacky version of what we’re aiming for, but ignore anything but the happy path. No error handling, no UI beyond the bare minimum, just the very core of what’s being done.
  - ess3 3y ago
    And on that note the ”trick” to being more experienced is being able to anticipate what’s coming up next and already have a mental model for how to solve that. Easier said than done though
- proper_elb 3y ago
  Heh, I don't think that will ever really change. What changes in my experience is your knowledge and confidence when it comes to translating requirements into maintainable technology. The real world stuff seems to be always messy. My attitude is to try to locate areas of potential unknown risk, plan how to deal with the known risk and then hack away, knowing that no matter how much time spent, the plan will be flawed. During this whole process, communication is really important (i.e. 30% feedback, where I just write comments of what I would change in the codebase and then talk about it with a collegue)
com2kid 3y ago
On the flip side, a lot of exploratory coding is often necessary to learn exactly what needs to be done. "Oh this API sometimes returns garbled garbage results, guess we need to write a sanitizer for its output" isn't something that is going to be known until at least some code is written.
- Chris_Newton 3y ago
  Definitely, exploratory coding can be very useful. It’s essentially writing code to help identify the requirements or design instead of to help implement them. As long as management understands that you might be writing different code for each case and you can’t necessarily turn one into the other…
geraldwhen 3y ago
For me it’s the main step. Decision making up front would require literally 40+ people, none of whom claim they have authority but all of whom say they MUST be involved in planning. Or, I could deploy something to QA and ask for feedback and forgiveness. Then a 3 week discussion becomes a 30 minute demo + a few small notes.
prox 3y ago
On this theme I can heartily recommend SovietWomble’s essay on the game the Forest (Soviet was a QA specialist in a former capacity) https://www.youtube.com/watch?v=PUWg905fGTA https://www.youtube.com/watch?v=PUWg905fGTA Both funny and insightful for anyone starting a project.

by m3kw9 3y ago

liamN 3y ago

For me, as a rookie developer, I find I often have little to no clue what needs to be done until I've started coding and figured out through trial and error how to implement it and what the requirements even should have been up front.

jon-wood 3y ago
Just because I feel more people should hear this early in their career, that’s perfectly normal. I fairly routinely answer questions about how long a piece of work is going to take by saying I’m going to need n days to work out what needs to be done, after which I’ll be able to give an estimate. That sort of exploratory work is really good because you’ll end up reading relevant documentation, then actually trying to use whatever it is you’re learning about. Often I’ll throw together a hacky version of what we’re aiming for, but ignore anything but the happy path. No error handling, no UI beyond the bare minimum, just the very core of what’s being done.
- ess3 3y ago
  And on that note the ”trick” to being more experienced is being able to anticipate what’s coming up next and already have a mental model for how to solve that. Easier said than done though
proper_elb 3y ago
Heh, I don't think that will ever really change. What changes in my experience is your knowledge and confidence when it comes to translating requirements into maintainable technology. The real world stuff seems to be always messy. My attitude is to try to locate areas of potential unknown risk, plan how to deal with the known risk and then hack away, knowing that no matter how much time spent, the plan will be flawed. During this whole process, communication is really important (i.e. 30% feedback, where I just write comments of what I would change in the codebase and then talk about it with a collegue)

com2kid 3y ago

On the flip side, a lot of exploratory coding is often necessary to learn exactly what needs to be done. "Oh this API sometimes returns garbled garbage results, guess we need to write a sanitizer for its output" isn't something that is going to be known until at least some code is written.

Chris_Newton 3y ago
Definitely, exploratory coding can be very useful. It’s essentially writing code to help identify the requirements or design instead of to help implement them. As long as management understands that you might be writing different code for each case and you can’t necessarily turn one into the other…

geraldwhen 3y ago

For me it’s the main step. Decision making up front would require literally 40+ people, none of whom claim they have authority but all of whom say they MUST be involved in planning. Or, I could deploy something to QA and ask for feedback and forgiveness. Then a 3 week discussion becomes a 30 minute demo + a few small notes.

prox 3y ago

On this theme I can heartily recommend SovietWomble’s essay on the game the Forest (Soviet was a QA specialist in a former capacity) https://www.youtube.com/watch?v=PUWg905fGTA https://www.youtube.com/watch?v=PUWg905fGTA Both funny and insightful for anyone starting a project.