7 ms·

What improved my coding a lot was simply taking responsibility of projects from start to deployment and beyond. Seeing the future damage of all your shortcuts o

by dep_b 10y ago

What improved my coding a lot was simply taking responsibility of projects from start to deployment and beyond. Seeing the future damage of all your shortcuts or entangling yourself in pretty patterns for no good at all really is sobering. You need to go through at least three Design-Ship-Support cycles of the same product to really appreciate what good coding practices are. If you're like one-of-many in a project and never really have responsibility for anything I would strongly recommend some external work where you are in total command of everything. I was stuck in a position without that for too long. ------------ By the way: you say you just know C. But how many developers out there feel bad about their skills because they don't have C skills? C is the beginning of everything, everything is built on top of it.

Klathmon 10y ago
This is what did it for me as well. Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And not just bugs or issues, but really feeling the pain of having to deploy it, talk on the phone with the customer and feel the lack of help/debugging stuff built-in to the product, train new users on how to use it, feel the panic as you realize that you cocked up the last deploy and it's going to be offline for like an hour while you scramble to roll back the changes which you thought you figured out months ago but everything changed since then and you are sitting there with nothing. Slowly but surely I started adding things to my "never do again" and my "needs to be done before launch" lists.
- FLUX-YOU 10y ago
  I have a position like this. It sucks. If you have to take total control of at least project, you'll likely be doing it for all projects. If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects. Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills). You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs. You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better. None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.
  - Klathmon 10y ago
    In my situation, it was a greenfield new-project which kind of started off as a "moonshot" and became a real thing, so mistakes and extra development time were much more tolerated (not to mention my employer is pretty awesome!). It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it). But holy hell did it teach me a lot!
  - busterarm 10y ago
    Me too :(
- jacobevelyn 10y ago
  Could you share some/all of your "never do again" and "needs to be done before launch" lists?
  - deleted 10y ago
    [deleted]
  - Klathmon 10y ago
    A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home: * Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind) * have a deploy plan that is one step * have a rollback plan that is one step * have backups running way before launch * have one-step restores from backup running before launch * make sure your restores make their own backup before running (yeah... that day sucked) * write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks * document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!) * make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!) * Have someone that is not a developer use the app without any documentation (this is huge) * Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work) * build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable) * Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with * make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master * plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here... * stick to a style guide * put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc... And a lot more i'm probably forgetting...
marktangotango 10y ago
There's nothing like realizing, that feature you polished like a jewel? When implementing it, you brought all the patterns and best practices to bear that you could. You archtitected the shit out of that thing! Yeah, no one uses that! That really puts things into perspective.
- Klathmon 10y ago
  My favorite story about that is I created a really nice series of components in React. Fully functional, stateless, really nice clean testable code. A user gets it, it's "too fast", the designer wants to put an animation in there to slow it down and help give some context. Of course the animation means that once you "clear" the dialog it flashes to blank before "animating away" (because it's a beautiful stateless functional component!). So now the code is this hideous hacky bloated ugly solution, but it works...
  - Rumudiez 10y ago
    The view is inherently stateful. Ignoring that because the JS doesn't have to be will always get you trouble. Adding transitions, however fast they may animate, will be killer.
    - Klathmon 10y ago
      I'm not shy of using internal state, but if I can get away with functional components, I will simply because of their simplicity and how easily they can be tested. But it was just more of a story about how sometimes ugly hacky code is better. Because at the end of the day, you are writing this for the user, not for yourself.
- shshhdhs 10y ago
  And to realize that feature was never invoked because you forgot to catch an exception a few lines before it.. Yeah.
gregmac 10y ago
There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call. I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message. That's the stuff that comes out in the Support cycle that I think people really only internalize if they learn the hard way.
- jjp 10y ago
  > There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call. Alternatively there's nothing like having a junior colleague investigating a defect in code you once wrote ask you what it does and then have to publicly declare that that it was crappy garbage that you can no longer decipher.
  - laythea 10y ago
    Years ago, I was the junior in this situation. Being very careful about how to criticize code publicly/not criticize is a skill in its own right!
  - ionforce 10y ago
    Nowadays I always write future proofing code. Like, if I need to make a bad decision/tech debt, I will leave ample documentation explaining why and providing alternatives in a hypothetical better future. My future self is always happy that this is the new standard. High quality, documented tech debt.
    - pards 10y ago
      I, too, started leaving comments for myself and other future maintainers to explain why a bad decision or awkward solution was chosen at the time, and offering the list of things I tried along with potential future improvements. Explaining the constraints under which the bad decision was made is important so that my future self can evaluate whether those constraints are still valid.
donmatito 10y ago
I would add : Design-Ship-SELL-Support cycle :-) Nothing as enlightening for a developer to get confronted to user frustration in the Support phase AND prospect's indifference in the Sell phase
walshemj 10y ago
Apart form a lot of Legacy COBOL or Fortran (for proper technical computing)
cr0sh 10y ago
> C is the beginning of everything, everything is built on top of it. I would argue that basic comp-sci principles and common language meta-syntax (mainly those derived from the fortran/pascal/c branch of things) is where everything (skills) should be built from. I'm not expressing this clearly; I know that. What I am trying to get across is that if you understand the fundamental principles (not necessarily the deep-dark parts of comp-sci where wizards roam) - you can apply those to almost any language (save for a handful or so - there are some languages out there that look very esoteric; LISP for one, but there are others on the functional language branch and other areas where the mindset for developing in them is quite different. That said, most of these "other" languages tend to be academic in usage (not that they aren't interesting in their own right!); that is, you won't generally find them much in the "real world" business area - not usually. However, sometimes you'll run across an employer or two willing to pay big bucks for that one expert developer to help them with their project in some language that isn't widely used. They are paying the money because the supply-demand curve is very skewed, but I would hesitate at taking such a position - while the money may be good, you could pigeon-hole yourself if you aren't careful.

by dep_b 10y ago

Klathmon 10y ago

This is what did it for me as well. Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And not just bugs or issues, but really feeling the pain of having to deploy it, talk on the phone with the customer and feel the lack of help/debugging stuff built-in to the product, train new users on how to use it, feel the panic as you realize that you cocked up the last deploy and it's going to be offline for like an hour while you scramble to roll back the changes which you thought you figured out months ago but everything changed since then and you are sitting there with nothing. Slowly but surely I started adding things to my "never do again" and my "needs to be done before launch" lists.

FLUX-YOU 10y ago
I have a position like this. It sucks. If you have to take total control of at least project, you'll likely be doing it for all projects. If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects. Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills). You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs. You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better. None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.
- Klathmon 10y ago
  In my situation, it was a greenfield new-project which kind of started off as a "moonshot" and became a real thing, so mistakes and extra development time were much more tolerated (not to mention my employer is pretty awesome!). It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it). But holy hell did it teach me a lot!
- busterarm 10y ago
  Me too :(
jacobevelyn 10y ago
Could you share some/all of your "never do again" and "needs to be done before launch" lists?
- deleted 10y ago
  [deleted]
- Klathmon 10y ago
  A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home: * Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind) * have a deploy plan that is one step * have a rollback plan that is one step * have backups running way before launch * have one-step restores from backup running before launch * make sure your restores make their own backup before running (yeah... that day sucked) * write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks * document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!) * make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!) * Have someone that is not a developer use the app without any documentation (this is huge) * Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work) * build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable) * Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with * make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master * plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here... * stick to a style guide * put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc... And a lot more i'm probably forgetting...

marktangotango 10y ago

There's nothing like realizing, that feature you polished like a jewel? When implementing it, you brought all the patterns and best practices to bear that you could. You archtitected the shit out of that thing! Yeah, no one uses that! That really puts things into perspective.

Klathmon 10y ago
My favorite story about that is I created a really nice series of components in React. Fully functional, stateless, really nice clean testable code. A user gets it, it's "too fast", the designer wants to put an animation in there to slow it down and help give some context. Of course the animation means that once you "clear" the dialog it flashes to blank before "animating away" (because it's a beautiful stateless functional component!). So now the code is this hideous hacky bloated ugly solution, but it works...
- Rumudiez 10y ago
  The view is inherently stateful. Ignoring that because the JS doesn't have to be will always get you trouble. Adding transitions, however fast they may animate, will be killer.
  - Klathmon 10y ago
    I'm not shy of using internal state, but if I can get away with functional components, I will simply because of their simplicity and how easily they can be tested. But it was just more of a story about how sometimes ugly hacky code is better. Because at the end of the day, you are writing this for the user, not for yourself.
shshhdhs 10y ago
And to realize that feature was never invoked because you forgot to catch an exception a few lines before it.. Yeah.

gregmac 10y ago

There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call. I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message. That's the stuff that comes out in the Support cycle that I think people really only internalize if they learn the hard way.

jjp 10y ago
> There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call. Alternatively there's nothing like having a junior colleague investigating a defect in code you once wrote ask you what it does and then have to publicly declare that that it was crappy garbage that you can no longer decipher.
- laythea 10y ago
  Years ago, I was the junior in this situation. Being very careful about how to criticize code publicly/not criticize is a skill in its own right!
- ionforce 10y ago
  Nowadays I always write future proofing code. Like, if I need to make a bad decision/tech debt, I will leave ample documentation explaining why and providing alternatives in a hypothetical better future. My future self is always happy that this is the new standard. High quality, documented tech debt.
  - pards 10y ago
    I, too, started leaving comments for myself and other future maintainers to explain why a bad decision or awkward solution was chosen at the time, and offering the list of things I tried along with potential future improvements. Explaining the constraints under which the bad decision was made is important so that my future self can evaluate whether those constraints are still valid.

donmatito 10y ago

I would add : Design-Ship-SELL-Support cycle :-) Nothing as enlightening for a developer to get confronted to user frustration in the Support phase AND prospect's indifference in the Sell phase

walshemj 10y ago

Apart form a lot of Legacy COBOL or Fortran (for proper technical computing)

cr0sh 10y ago

> C is the beginning of everything, everything is built on top of it. I would argue that basic comp-sci principles and common language meta-syntax (mainly those derived from the fortran/pascal/c branch of things) is where everything (skills) should be built from. I'm not expressing this clearly; I know that. What I am trying to get across is that if you understand the fundamental principles (not necessarily the deep-dark parts of comp-sci where wizards roam) - you can apply those to almost any language (save for a handful or so - there are some languages out there that look very esoteric; LISP for one, but there are others on the functional language branch and other areas where the mindset for developing in them is quite different. That said, most of these "other" languages tend to be academic in usage (not that they aren't interesting in their own right!); that is, you won't generally find them much in the "real world" business area - not usually. However, sometimes you'll run across an employer or two willing to pay big bucks for that one expert developer to help them with their project in some language that isn't widely used. They are paying the money because the supply-demand curve is very skewed, but I would hesitate at taking such a position - while the money may be good, you could pigeon-hole yourself if you aren't careful.