If your workplace is optimizing for your enjoyment, there is probably a serious problem afoot. The value of thinking ahead, to be clear, is that it enables you to "actually create" something that isn't ill thought out, or worse, of no actual use to any person. It also allows your work to be understood by other people, who might have to duplicate it, review it, or extend it in the future. It is indeed unfortunate that all of these legitimate demands should intrude on your time that could instead be spent spewing out code.
Have to disagree. Many places try to optimize for enjoyment so they can keep their employees.
There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.
> It was actually mandated for many government projects for a while
I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.
In many industries as well as many government branches it still works just like that. They do not mandate a way of "writing the code", but software projects must pass gates and receive approvals at each stage before getting funding. They have to provide comprehensive analysis and architecture documentation that cover everything under the sun before a single line of code is written. And then, once a dev team starts coding, it has to go through the whole loop and if something specified doesn't make sense "on the real world". Or, more often, they just do the proper thing without telling anyone.
Interesting! Too young to have experienced waterfall model in a workplace. Are you saying it did not exists. If so what was the agile manifest a response to?
Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).
Writing down what you intend to do and verifying with your team it is sensible is not "the waterfall model". This "I just want to code" attitude is a major disease of young programmers and a leading cause of shitty software. Think ahead. Write it down. You are not a lonesome dove.
Thats a fair point, but I did not say that there should be no communication about the work you do. We all work differently and I think it is sensible to let each employee have some form of independence of how they want to structure their own work. If the feature is a few days of work let me work on it like I prefer and then I can submit with a nice description and thought process.
Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.
Again, there is no justification for just jumping in and writing code. Would you cut wood without measuring it first? Would you start soldering without laying out a circuit? Would you write an essay without an outline? You could do all of these things, but the results are guaranteed to be crap.
