I think this is a pretty common career progression. Coding can be fun and rewarding but I’ve written hundreds of thousands - possibly millions - of lines of code in a dozen languages and there is very little novelty left for me. The challenges of team organization, project planning, and personnel issues are more attractive right now.
You'd think that, but I worked with a guy going on 20 years of experience who seemed to be the embodiment of code first, ask questions later. He coded quickly and abundantly, but man it was crap code. He'd get assigned a story and go off and do what he thought it said but more often than not missed the real point of what the request was.
Planning is like 80% of the work to me.
Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things they've not yet thought about.
This Android component doesn't allow styling without modifying the library object itself, for no good reason aside from whichever intern wrote it was lazy and nobody at Google cares about anything, so it made it through.
Ulimit exists, guess I should go fuck myself.
AWS says it supports this language for lambdas but it kinda doesn't if you look at the bug tracker for the tools.
This fancy new build tool someone else chose breaks this third party package in a way that goes away immediately if I just swap it for the old, uncool build tool.
That kind of crap. And it's the worst part of programming. There are also "real" problems, but they're the minority.
Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is.
You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks.
But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, how to roll it back if you screw up, etc.
I find that many people use agile as an excuse to ignore these questions and just pile up fixes on top of prototypes.
Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done.
Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
I did, and here's the direct quotes:
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
As I said, the cycle length is shortened, yet...
> Continuous attention to technical excellence and good design enhances agility.
...design is not removed from the process, but kept as a cornerstone.
> Simplicity--the art of maximizing the amount of work not done--is essential.
This one might be a bit more of a stretch, but I see here the benefit of designing a simple, elegant solution rather than doing work straight ahead.
In any case, I don't fully agree with the agile manifesto, even when correctly implemented. Particularly this quote is the bane of my existence:
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Which you can identify as the very opposite of the ever popular 'this meeting could have been an email'.
Once you put it together, you'll realize that the message is:
1. Deliver software. You won't have a manager hounding you to do so.
2. Do good work. You won't have a manager questioning what you've done.
3. Don't spend more time programming than you need to. You need time for managerial tasks.
4. Meet with your teammates. You won't have a manager to act as the go-between.
My opinion is based on being a software engineer (junior through principal) at small, medium, and fortune 100 companies. I also have years of experience as an engineering manager.
It’s silly to be absolute about it, but I think there’s probably a large overlap between competent engineers and people that agree that the agile manifesto is generally a good thing.
What says that? The Manifesto is there to help guide you if your group chooses to forego managers, but it doesn't suggest not having managers is the right tool for the job. An engineer more than anyone should understand the concept of tradeoffs.
We're building entire skyscrapers and cathedrals by gluing a few toothpicks together at a time. Because that's all there's time for in a sprint. It shows in the quality of modern software, and the never-ending updates necessary to keep them from collapsing.
Of course planning it all out years in advance and then executing blindly on those plans without ever correcting course wouldn't make sense either. But maybe a middle ground could be better than either extreme.
I get what you're saying though, I definitely don't think I'm solving all my problems before ever starting the code, but I definitely always finish solving the problem before I finish the code, and usually early enough that the rest of implementation drags even if there are quirks and edge cases to work out.
The main lesson I've drawn is that never propose a technical solution that you didn't PoC and that you only have validated the parts of the system you implemented. Deletion is often harder than creation.
You have to do the stuff you don't like to get to stuff you do sometimes.
I can relate to this so much sometimes. Right now I'm putting off programming because the ticket I have I've already thought through in my head and now I'm sitting here goofing off on here and reddit because I just don't want to do the actual work part.
And as another commenter chimed in, its true that some problems only emerge once you start writing the code. But that's alright, its part of the process. The planning isn't so much to figure out every problem ever, but to model the known problems so that programming the solutions can begin. I go back and forth between white-boarding and coding as things emerge.
I always tell myself that if I'm sitting at the keyboard and I don't know what to type, it's time to go back to the whiteboard because I'm not understanding the problem.
edit: clarity
Two factors cause this to be an exercise in futility:
1. Job mobility
People are incentivized to job hop. Most employees are ramping into a new role, coasting/leetcoding while they interview elsewhere, or preparing to transfer to a new role in your company.
In a 1.5 year employment window in a given role, a team member may only be getting 6 months of productive time in the new work paradigm.
2. Capricious Management culture
The new era of tech has ushered in a fickle type of boss who has constant pivots, realignments, and shifting priorities. They speak of some utopian future for your organization and paint a picture that everything is always 'in transition'.
This means that nobody seriously considers your CICD or Agile paradigm to be a permanent thing... you only get half hearted attempts to follow it for the 8 months that it lasts before a new paradigm is forced onto your group.
Overviews of the problem are more in the realm of spec rather than implementation planning and is another issue altogether. Of course you need to know what you're solving, but it is my point that I don't need to write a detailed document on how I'm going to solve most everyday problems when I can jump into the code and progressively work from there using the tools provided by the language.
At my work though, if you're going to adopt a major framework or service, you need a doc explaining why you chose that one. It's a big decision that will last years.
Full agreement. It's a rare skill.
> I am the exact opposite. I mean, I don’t like processes and meetings
Am I the only one that enjoys meetings?
I enjoy listening to other perspectives, challenge and be challenged, collaborate on complex problems, find collectively better solutions, develop meaningful personal relationships, and through work become a better person.
If the problem is solved before I write code I’m not really interested in writing code. I crave problems that require experimentation, where the solution isn’t obvious.
Have you worked on problem spaces that are either so vague, or so large that it’s impossible to form a mental model?
That’s when I just jump into coding, because there’s no alternatives. Whatever I produce will make the powers that be able to crystalize what they actually want.
The mistake is by other people who think that your first efforts represent the product and need to be shipped.
It almost works except that no one really understands the problems you're presenting because they've all got their own problems to deal with. It's more helpful as a duck.
Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved.
I’ve never understood people that just jump into coding without much of a plan - and I think the industry has shifted towards that a lot these past years. Everyone is used to learning by doing, and pretty much everyone seems to have an aversion towards reading and documenting. I feel I’m slowly becoming part of a minority.