4
Tounai
5d

Might be controversial here, but to me there’s two types of software engineers

- those who like to spec everything before, fully document their approach
- those who start with rough, broken code and carve the stone through time

And I believe it’s two irreconcilable styles, so when both are present in a company, it necessarily ends up with a war

Comments
  • 3
    idk how you could spec everything

    you'd never learn anything new?
  • 3
    There is also explorative programming. Doesn’t need to be broken code.

    Bit yes, the different styles will clash in a company.
  • 2
    Vibing I'm 100% first one. Private projects the second one. Professionally company depended I guess.
  • 2
    @Lensflare to me explorative programming is the same as broken, but I prefer this way rather than specing everything.
  • 1
    Yup, PM wants 1 everyone else does 2, he still cries about it. I'm sure we'll all be replaced slowly, as they don't fire him, no matter how many times people complain...
  • 2
    I don't think it's controversial, I think it's just not true. Different situations require different approaches. I've mixed the to up quite a bit. Had to really push for 1. at times because dumbasses like to use agile as a magic keyword to not think things through and not supply enough info or content to go beyond 2 days of development.
  • 5
    Or you can do a little bit of both. Works best for my use cases.

    Define high-level plans in advance with contract layers set or partially set, define epics and their DoDs, assume they will work, and split all of them into tasks, divide across teams. Let them figure out ["carve out"] the solutions. Then in the end make final adjustments to both impl and contracts and voila. All teams were creating value, client had a pretty good definition of what's going to happen, with some RnD DoDs have been achieved.
  • 1
    yeah I had architects and their plans often were not gonna be the literal solution

    a spec is nice but it's not necessarily the best or even a workable design. it's a rough direction to get you started

    (and then I went back and changed the architecture drawings to be how the code actually was)
Add Comment