9 ms·

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 co

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.

flatline 4y ago
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.
- cratermoon 4y ago
  > 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.
- yamtaddle 4y ago
  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.
crgi 4y ago
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.
ahartmetz 4y ago
You might want to become some kind of technically minded product manager? Good people seem to be especially rare (therefore valuable) in product management.
busterarm 4y ago
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.
matsemann 4y ago
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.
- yamtaddle 4y ago
  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.
- torben-friis 4y ago
  > 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.
  - icedchai 4y ago
    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!
hk1337 4y ago
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.
meese712 4y ago
> 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.
rytor718 4y ago
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
chinchilla2020 4y ago
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.
mixedCase 4y ago
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.
- 8n4vidtmkvmk 4y ago
  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.
  - mixedCase 4y ago
    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.
    - 8n4vidtmkvmk 4y ago
      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.
harrego 4y ago
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."
deleted 4y ago
[deleted]
rlt 4y ago
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…
escapedmoose 4y ago
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 :)
Aeolun 4y ago
> 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.
- t43562 4y ago
  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.
8n4vidtmkvmk 4y ago
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.

flatline 4y ago

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.

cratermoon 4y ago
> 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.
yamtaddle 4y ago
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.

crgi 4y ago

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.

ahartmetz 4y ago

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

busterarm 4y ago

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.

matsemann 4y ago

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.

yamtaddle 4y ago
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.
torben-friis 4y ago
> 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.
- icedchai 4y ago
  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!

hk1337 4y ago

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.

meese712 4y ago

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

rytor718 4y ago

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

chinchilla2020 4y ago

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.

mixedCase 4y ago

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.

8n4vidtmkvmk 4y ago
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.
- mixedCase 4y ago
  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.
  - 8n4vidtmkvmk 4y ago
    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.

harrego 4y ago

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

deleted 4y ago

[deleted]

rlt 4y ago

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…

escapedmoose 4y ago

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 :)

Aeolun 4y ago

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

t43562 4y ago
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.

8n4vidtmkvmk 4y ago

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.