4 ms·

Or he just bangs out a ton of crappy code in the name of "pragmatism", while everyone else has to clean up after him and thus takes longer. I've seen this many

by tsss 4y ago

Or he just bangs out a ton of crappy code in the name of "pragmatism", while everyone else has to clean up after him and thus takes longer. I've seen this many times.

andrewmcwatters 4y ago
This could be the case, but we don't know, and it's also helpful to think about this from a charitable perspective.
- 100011_100001 4y ago
  I prefer this perspective :) Honestly, I have no need for validation. I've just started to feel angst and figured if there is a place where I can get good advice, even if it hurts, it would be HN. From that perspective I have gotten enough good input to make this thread worth it to me.
100011_100001 4y ago
Eh, that is exactly what I don't want. Pretending I am this amazingly productive developer and my code is just trash. I just checked. In 2021, only two defects were created against my specific code changes. If I had to home into a weakness of mine is that sometimes I solve today's problem well, but don't think extensively about how tomorrow's problem in that space might look like. The struggle is between creating simple solutions vs over-engineering for future proofing. I'm pretty sure I'm biased towards simple solutions.
- beardedetim 4y ago
  > The struggle is between creating simple solutions vs over-engineering for future proofing. I'm pretty sure I'm biased towards simple solutions. I want to encourage you to keep learning about your own biases here but to continue to have that bias as much as possible. I like the term "throw away code" here but I think another way to say it would be that most of the code I write is like a jig for woodworking. I don't need it at the end of the day, it looks like shit, and holds up the real Things while I figure out how those things actually work. Sometimes in code though, I find, that the jig _is good enough for now_ and it's super easy to replace the three that break instead of all 20 I needed to build it.
- tsss 4y ago
  It's not about behavioural defects. It's that the _code_ is trash. It is unmaintainable and slows down all future changes, exactly because the person who wrote it didn't take the time to think about the future or even good architecture in the present. Every time I touch their code I have to almost redo their work because: - It's impossible to understand what is going on (For example when people load huge json or sql files into a single test and you don't know what scenarios it covers because they are too lazy to write dedicated minimal test cases. Another common offense is a not well-defined data model that gets mutated everywhere in dynamic languages like Python or JavaScript where you never know what shape an object has or where it comes from) - Their code allows so little extensibility that following the same "pragmatism" as they did and just hacking it in would exponentially increase the complexity - There are no abstraction boundaries which almost surely means insufficient test coverage (which I have to amend before I can even start with my own work so that I don't introduce regressions) or the tests are coupled so closely to implementation details that any change necessary for my own work will require me to rewrite all the existing tests You are fast because you pawn off your design work to whoever comes after you. Of course you have fewer defects: your colleagues have to put in more time to maintain the same level of correctness or else risk introducing bugs. That's the cost of bad maintainability. It's well known that changing existing code is harder than writing new code, double so if it is not written with care. Someone has to be the janitor to keep the cruft from accumulating and if it's not you, then everyone else has to pick up your slack. Ideally, every person in the team would continually clean up and always leave a code base better than they found it. Lastly, I want to say that there is very important difference between simple and easy and simple doesn't come for free.
  - 100011_100001 4y ago
    It sounds like you have personal experience in this. I hear you. From what I have observed through code reviews that I, or others, have looked at that doesn't happen with my code unless there is a very fundamental shift. Even then I try to keep my inputs and outputs clean so that pieces can be removed if need be. Of course I am not always as successful as I would like to be. Now my first 2-4 years, that happened a lot, and I am not going to claim that I was fast. I was slow and either the code review would point something out that I would literary have to start from scratch or the next person that touched it would have to. This was actually the driver for me to focus more on simplicity. I basically discovered a direct correlation between complexity and how bad my code was. To this day, if I catch myself doing something overtly complex it's a sign that my solution to the current problem is inadequate. Ironically, my response would be the same if my code was trash. So I won't be able to convince you regardless.
- bigbizisverywyz 4y ago
  Have you thought about, or are you already involved in interviewing new developers for the company? It sounds like you might already have a nose for what makes a good dev (i.e. somebody who holds the same values as you) It's a great way to influence the company culture, and get good co-workers, which can also de-stress you as you now have fellow travelers whom you can trust with tasks. It's also fun, sometimes humbling but always interesting!
ptr 4y ago
You can be fast while also writing great code.
- Thomassgrey1 4y ago

by tsss 4y ago

Or he just bangs out a ton of crappy code in the name of "pragmatism", while everyone else has to clean up after him and thus takes longer. I've seen this many times.

andrewmcwatters 4y ago

This could be the case, but we don't know, and it's also helpful to think about this from a charitable perspective.

100011_100001 4y ago
I prefer this perspective :) Honestly, I have no need for validation. I've just started to feel angst and figured if there is a place where I can get good advice, even if it hurts, it would be HN. From that perspective I have gotten enough good input to make this thread worth it to me.

100011_100001 4y ago

Eh, that is exactly what I don't want. Pretending I am this amazingly productive developer and my code is just trash. I just checked. In 2021, only two defects were created against my specific code changes. If I had to home into a weakness of mine is that sometimes I solve today's problem well, but don't think extensively about how tomorrow's problem in that space might look like. The struggle is between creating simple solutions vs over-engineering for future proofing. I'm pretty sure I'm biased towards simple solutions.

beardedetim 4y ago
> The struggle is between creating simple solutions vs over-engineering for future proofing. I'm pretty sure I'm biased towards simple solutions. I want to encourage you to keep learning about your own biases here but to continue to have that bias as much as possible. I like the term "throw away code" here but I think another way to say it would be that most of the code I write is like a jig for woodworking. I don't need it at the end of the day, it looks like shit, and holds up the real Things while I figure out how those things actually work. Sometimes in code though, I find, that the jig _is good enough for now_ and it's super easy to replace the three that break instead of all 20 I needed to build it.
tsss 4y ago
It's not about behavioural defects. It's that the _code_ is trash. It is unmaintainable and slows down all future changes, exactly because the person who wrote it didn't take the time to think about the future or even good architecture in the present. Every time I touch their code I have to almost redo their work because: - It's impossible to understand what is going on (For example when people load huge json or sql files into a single test and you don't know what scenarios it covers because they are too lazy to write dedicated minimal test cases. Another common offense is a not well-defined data model that gets mutated everywhere in dynamic languages like Python or JavaScript where you never know what shape an object has or where it comes from) - Their code allows so little extensibility that following the same "pragmatism" as they did and just hacking it in would exponentially increase the complexity - There are no abstraction boundaries which almost surely means insufficient test coverage (which I have to amend before I can even start with my own work so that I don't introduce regressions) or the tests are coupled so closely to implementation details that any change necessary for my own work will require me to rewrite all the existing tests You are fast because you pawn off your design work to whoever comes after you. Of course you have fewer defects: your colleagues have to put in more time to maintain the same level of correctness or else risk introducing bugs. That's the cost of bad maintainability. It's well known that changing existing code is harder than writing new code, double so if it is not written with care. Someone has to be the janitor to keep the cruft from accumulating and if it's not you, then everyone else has to pick up your slack. Ideally, every person in the team would continually clean up and always leave a code base better than they found it. Lastly, I want to say that there is very important difference between simple and easy and simple doesn't come for free.
- 100011_100001 4y ago
  It sounds like you have personal experience in this. I hear you. From what I have observed through code reviews that I, or others, have looked at that doesn't happen with my code unless there is a very fundamental shift. Even then I try to keep my inputs and outputs clean so that pieces can be removed if need be. Of course I am not always as successful as I would like to be. Now my first 2-4 years, that happened a lot, and I am not going to claim that I was fast. I was slow and either the code review would point something out that I would literary have to start from scratch or the next person that touched it would have to. This was actually the driver for me to focus more on simplicity. I basically discovered a direct correlation between complexity and how bad my code was. To this day, if I catch myself doing something overtly complex it's a sign that my solution to the current problem is inadequate. Ironically, my response would be the same if my code was trash. So I won't be able to convince you regardless.
bigbizisverywyz 4y ago
Have you thought about, or are you already involved in interviewing new developers for the company? It sounds like you might already have a nose for what makes a good dev (i.e. somebody who holds the same values as you) It's a great way to influence the company culture, and get good co-workers, which can also de-stress you as you now have fellow travelers whom you can trust with tasks. It's also fun, sometimes humbling but always interesting!

ptr 4y ago

You can be fast while also writing great code.

Thomassgrey1 4y ago