Hacker News Reader

Comment by torben-friis | Hacker News Reader

I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code.

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.

View on HN

Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever.

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.

I'd agree that an awful lot of the problems I run into are dumb trivial shit, once the "real work" starts.

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.

> It's a reason waterfall was abandoned.

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.

Exactly this. Agile is often seen as an excuse to throw out any sort of design. You wind up with fixing the mess made last sprint in the next. But, good news, there are Jira tickets with points assigned for the half-baked fixes!

> 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.

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.

> Read the Manifesto again.

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'.

Now read it again as the entire document that it is. While I can see where you are coming from, your theme doesn't carry into the points you conveniently left out.

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.

Being a developer without a good Engineering Manager is a futile exercise in my experience. Software developers deliver quality work and solve problems efficiently as a matter course. If not, they should be let go to work someplace else, potentially outside the software trade. Saying those skills are exclusive to followers of the agile manifesto is silly. Find a good manager that brings you opportunities and respects your expertise. If your manager hasn't put you in a place to be the rock star in the last year or so you need to move on or accept you aren't "all that".

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.

> Saying those skills are exclusive to followers of the agile manifesto is silly

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.

That's fair. In that spectrum I'd rank folks that see agile as but one tool in the shed higher than those that agree it's _the_ way to execute projects.

> Saying those skills are exclusive to followers of the agile manifesto is silly.

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.

Despite having somehow done this successfully for many years, I still find 2 weeks total for the entirety of requirements gathering, planning, designing, developing, reviewing, and testing (plus all the meetings and documentation and jira cards etc.) is kind of an incomprehensible timeline for anything but the most trivial fix.

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.

Problems are often "sticky" (A term I've read referencing this exact thing, a problem where you need to begin implementing before you understand it fully, but I don't think it's a widely used term) but I think the implementation step is a different matter than architecture stuff regardless. It's not that there aren't important things to work out, but for me I broadly consider that to be part of the implementation.

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.

Yeah this is quite common, somehow I sympathize with both gp and submitter here, the last year I have tried suffered under a group of architects that have greenlit a project where we have now wasted about a man century. All because we ramped up fast into a "fully sovled problem" with new "well understood architectural patterns and design philosophy". And these are not "23 year old CTO" type people, it's people with 25+ years as "enterprise architect" in FAANG type companies.

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.

I dont know about you but virtually every team still uses waterfall at some scale

True, so if you’re a planning type of person, you need to have realistic expectations about your unknown unknowns. Humility helps. But the people who go straight to the keyboard to figure it out as they go can spin their wheels just as bad.

Early in my career I started out just writing code for every problem. Now I loathe the prospect of writing a line of code unless I’m sure it’s not a waste of time. It can be exploratory code, but I need to know in advance exactly what questions I want it to answer, so even if I throw it away it definitively tells me a path I should not go down.

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.

> I think this is a pretty common career progression

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.

Agreed. These days every time I'm writing code I can't help but feel it's because I didn't know enough to be able to avoid writing it.

I'm with you too here. I always chafe and find minor conflict with the types of engineers that just want to head down, headphones on and write code all day long.

Planning is like 80% of the work to me.

Same for me. Jumping into the code can be fun at times. But if the software is not modelled well, a lot of bugs will orginate from structural issues. When you see those, the bugs become anoying to fix because you basically know new ones will pop up eventually since the root cause is not adressed. Applying concepts like DDD will be of very little value without a profound understanding of the domain at hand. This is mostly established by non-coding activities.

Unfortunately, it takes 6 months to a year to fully cultivate a strong culture around a process.

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.

> 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 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.

Would it help if, as someone on the other side that for the most part only plans as the feature is discussed on their head and then jumps into code, I say that the code is where I "document" my plans as types, comments, tests, and stubs, which I progressively expand into implementations? On the same vein, I'd add that some languages greatly facilitate this process, while others make it more of a pain.

I don't think that counts. I love code but code doesn't capture the "whys". It's also not very good at giving an overview of the problem.

The "why" is pretty much the only reason to write comments!

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.

Most everyday problems don't need a doc to explain what you're going to do.

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.

> I’ve never understood people that just jump into coding without much of a plan

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.

Absolutely. The act of trying to write code immediately brings out the questions that you end up needing to answer in a design.

The mistake is by other people who think that your first efforts represent the product and need to be shipped.

I feel like I am in between. I learn better by doing but I think everyone thinks they have to move so fast, be agile, that they leave their shitty implementation doing the work instead of figuring out how to rewrite it into something more manageable.

You have to do the stuff you don't like to get to stuff you do sometimes.

This is when programming really clicked for me: I learned that if the problem isn't well understood and solved before you sit down to write a line of code, then its not time to code yet. Model the problem space first.

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

I am stunned by how close this description aligns with my thinking. I think that reading and prior consideration are fast fading in this industry for the reason you put so well, "everyone is used to learning by doing."

I sometimes start coding without much of a plan. Then I get a little ways in, start seeing all the problems, start jotting down solutions with pen and paper and then realize hmm.. maybe I should write a proper doc and solicit feedback.

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.

You might want to become some kind of technically minded product manager? Good people seem to be especially rare (therefore valuable) in product management.

It’s interesting how opposite people in nominally the same profession can be.

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.

On the other hand, it’s a reason I have trouble completing projects. Once I prove to myself it’s feasible I get bored with finishing it…

I’m with you. Everything gets scribbled out on paper before I touch the keyboard. And I’ve documented most of the solution before finishing half the code. It’s niche that we can find a niche at least :)

Reply on news.ycombinator.com