8 ms·

Best thing about 20 years of freelancing has been that I have NEVER been asked about, ridiculed for, or heard complaining about my code. Nobody even sees it, or

by dpcan 7y ago

Best thing about 20 years of freelancing has been that I have NEVER been asked about, ridiculed for, or heard complaining about my code. Nobody even sees it, or cares. It's efficient and responsible code in my opinion, but I don't have to care about this strange problem where programmers actually have opinions about how code is put together. I don't know how you guys put up with it, I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever.

SahAssar 7y ago
I think we put up with it because personal development requires outside feedback. I couldn't imagine getting better at the pace I am without both having to justify and explain my decisions to others. I don't understand your viewpoint at all. The best part about coding for me is getting a review with a lot of interesting comments about how it could be done differently. It jogs my brain down paths I would never have seen by myself.
- kareemm 7y ago
  As a consultant (not the OP) one of the best parts of writing code is having it solve real business problems (and getting paid well for it). It's a point of personal pride to write reasonably good code, but the structure doesn't matter to the person paying the bills - the outcome does. It's like living in a house: as long as it doesn't fall down and doesn't cost unreasonable amounts to maintain, I don't really care about how well-formed the mortar is, or that the drywall is hung perfectly according to company standards. I just want to live in the house and not worry about it.
  - SahAssar 7y ago
    Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not you you are imposing a single persons idea of what the business problem is and how it should be solved on the maintainer, which they might not agree with * Personal development depends on realizing when you are wrong or have used the wrong tool. If nobody challenges your decisions you will probably not realize that as often (or at all) and therefore not improve as much. * Solving business problems means solving problems for a business. Usually businesses evolve over time, so the business problems might change. Who will understand the code in that case? How do you know the code is understandable to other people if nobody else reviewed it? And as for the house example: before buying that house I would definitely hire somebody else to check it, and that is legally required in some countries. I don't trust anyone to rate their own work. In this case the person who hired your consultancy bought the house, and they should definitely have an expert that did not build it check it. --- Just a FYI: I'm also a consultant, but work on a project where we have discussions about how to structure the code and do code reviews and so on.
    - kareemm 7y ago
      Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.
  - dwild 7y ago
    The structure does have an impact on its maintainability though. You said you don't care about well-formed the mortar is or how the drywall is hung, but would you care if it was made in a way that would make it much harder later on to run new wires inside the wall? I would care personnaly. > writing code is having it solve real business problems Sure, but writing good code is about solving future problem the business is going to have too. A problem has more than a single dimension. If your code will never evolve, if it's a definitive solution to their problems, the structure doesn't matter that's true, but sadly, that's almost never the case.
  - alfalfasprout 7y ago
    It's like building someone a house where the design is flawed and someday it'll fall down and kill everyone. By the time it happens, you'll be long gone. Doesn't mean it's the right thing to do.
  - dragonwriter 7y ago
    > the structure doesn't matter to the person paying the bills - the outcome does. The structure matters to the outcome; but the outcome problems of bad structure tend to manifest after paid-by-engagement contractors have left.
- vbezhenar 7y ago
  > personal development requires outside feedback Is it true? If I read book or blog, I improve my skills. Sure, feedback helps but I don't think that it's a hard requirement.
  - SuperFerret 7y ago
    I would challenge you to find a profession that doesn't benefit greatly from peer review and feedback.
  - throwaway894345 7y ago
    In my personal experience, reading alone is less efficient by at least 1 order of magnitude.
  - hombre_fatal 7y ago
    I don't think anything is quite as effective as having a conversation with others. It challenges you in a deep, possibly mind-changing way that a book cannot. I didn't quite realize this until, after 5 years of building things on my own, I had a co-founder. I feel like I gained 10 years of experience just from working with him and having to explain my solutions or why I didn't consider this other one, or having to realize that I was in fact wrong. That's a hard pill to swallow when you've only worked with books. Craftsmanship is more than just learning new things. Sometimes you need to have your entire model of what's best swapped out for new ideas, like society realizing a republic is better than feudalism, than never evolving past your original position.
  - kqr 7y ago
    The steel man of that argument is that yes, with no feedback you have nothing to evaluate your decisions against, and all feedback is outside feedback. That said, I think the person you're responding to meant outside feedback as in opinions from peers, which I agree is very powerful, but not strictly necessary.
- jariel 7y ago
  "because personal development " 2) standard practices, idioms, consistency. You can't use tabs if the entire company uses spaces or use Python if it's a Java shop. 3) Because in most cases, an extra set of eyes can help provide real, material constructive feedback. I have little trust that any standalone developer is going to just write 'solid code'. Who has that level of self-awareness to recognize they are 'that good', let alone actually be good without help? It's a basic matter of professionalism to work with others and to be good team members, without it, we're not going to get much done. For smaller projects with very clear requirements, it matters less.
- austincheney 7y ago
  For me, as a developer who maintains open source software, the best feedback has nothing to do with the code. Honestly, nobody cares. The application does what it claims or it doesn't. People who spend all their energy on code style have clearly, in my opinion, never had the experience of directly interfacing with their users. Here is my checklist of competence: * defects - The application has certain defects or it doesn't and you can prove it with tests. If there is a defect I will prioritize it, or solve it immediately, or mark it as won't fix. * performance - Does the application execute fast enough in all stages and interactions? This is a simple yes or no, but performance testing is often volatile so this needs to be tested and measured as well so that it can be observed over time keeping slippage in mind. * ease of use - Does the application work out of the box? If not its broken. If it requires a bunch of manual configuration then nobody will use unless its forced on them. For this I take all my frustrations with corporate software from my past jobs and I intentionally design against that when I write software and encourage my users to complain to me. * documentation - Does the documentation stand on its own? Is it complete, well organized, and simple enough that a high school freshman can read it? If you cannot write you aren't as great a developer as you think you are.
  - croo 7y ago
    > Honestly, nobody cares Other programmers care. A one/two man workshop doesn't need order or processes to get things done. A ten man workshop cannot function without it. The same is true with coding - it becomes a tool for programmers to communicate intent, it's becomes important to be ordered, clean and understandable by every other dev.
    - austincheney 7y ago
      The end users of my open source software are all developers and they never complained about the code style. Not once. My largest application lived for 10 years and was used by hundreds of thousands of people. > it's becomes important to be ordered, clean and understandable by every other dev Code style is the wrong tool for that job. Better are code reviews and written documentation.
  - 7y ago
- winrid 7y ago
  Maybe this person is just against nitpicking..?
- P_I_Staker 7y ago
  Not to mention you need teams to solve larger problems and/or support more customers. So OP's comment basically amounts to a cruel boast about the BS he doesn't have to put up with. It'd be like telling a construction worker taking a water break: "That's the nice thing about the office jobs. No need to worry about hydration because I'm not out in the hot sun all day." I have a feeling this kind of observation would not be well received.
- dpcan 7y ago
  Yeah, I don't really need that. I like to learn to do new things, and my passion is coding and tinkering with projects and learning new tech, so I have no problem finding my way down new avenues of doing things. It's the petty stuff that I hate. I did work somewhere during the dot-com years and we had an entire meeting about double spacing. Whether we press enter TWICE after an if-statement bracket, or once. I hated every second of it.
daenz 7y ago
Do you not see value in more experienced people giving you feedback on how to tackle a problem better?
johnchristopher 7y ago
> I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever. It really depends on the industry your work with, code base size and number of contributors.
johnchristopher 7y ago
> I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever Yeah, but they usually have loaded guns to our head so we tend to comply. Jeez.
ben509 7y ago
Working a similar number of years in various corporate jobs, I haven't seen too much of that, but it does happen. I'm probably my harshest critic when I'm looking at code I wrote years ago. Or maybe someone is cursing me after I've moved on. I wonder, you've never been critiqued, but how many times have you gotten a project and had to unravel badly written code? I think the macro-style issues people debate are mostly about code that is being maintained and reworked over and over again in a product with a long life. > I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever. Those issues all have root causes you must have dealt with. Tabs vs. spaces type stuff is mostly about keeping diffs clean in a repo. Language choice is just a matter of components being able to work together, and being able to hire people who can work on it. And choices like "more classes" are usually revolving around testability of code. > I don't know how you guys put up with it Absolutely, maintaining a product over a long period of time can be exhausting. I think there are benefits to it, though. It's extremely gratifying when you've written something that someone else builds on and they actually get the structure and their new code fits in very closely to how you intended. The whole thing kind of becomes your baby, albeit a baby that you're thinking, "one of these days I'm going to cut her head off and stitch a new one on and she'll be way cuter."
pixelbash 7y ago
I was in this boat for 8 years or so before starting a company and hiring a second developer. I lucked out and got a highly research driven one to learn from, and I gotta say I've learned a ton in 2 years. Even if it's harder in some ways than being solo, I think it's been worth it to have that pressure to improve code and processes. I was kind of coasting before if I'm honest, even though I felt like I was really good at my job.
alexbanks 7y ago
This sounds like a dangerous mindset. "I don't ever want to even hear about it if what I'm doing is ridiculous". I am not attacking you or saying that what you're doing is wrong, I'm just curious/cautious about the motives behind not wanting to know if there are better/more productive ways of doing things that you just might not know about? Collaboration is usually a very good thing, in spite of the small % of terrible teammates you occasionally get.
- therealx 7y ago
  It depends on the person. Not everyone needs code review to strive for better and know when you're doing poorly. Collaboration is an easy way to get that, but it's not required. The same people that have the personality to learn things on their own often are the same that will improve their code over time without someone else.
gmanley 7y ago
Different perspectives help you grow. I can't imagine not getting feedback. We aren't ridiculed about code structure but given feedback that you can take, or not, with a discussion. It seems pretty problematic that getting feedback would make you "go nuts". Obviously this depends on the organization but, most of the time, I'm not talking about superficial stuff, like tabs over space, but legitimate changes that can improve my code. No one writes nothing but perfect code and having someone double check you can be immensely valuable.
vbezhenar 7y ago
I'm in a similar boat. When I started programming, I always was the smartest guy in the company so I never had a chance to improve from feedback. Last years I'm alone as a programmer and I love it. If someone would criticize my code, that probably would make be very unhappy and I probably will fight that, because every critique I can imagine will be based on subjective factors (of course bugs are objective, but I don't usually write buggy code). I guess, some people just better left alone as long as they can find someone ready to pay them. The downside is that I can't really write big projects. My biggest projects are few dozens of thousands of LoC and typical project is few thousands of LoC. They are pretty useful to end-users, though, but participating in some huge project with millions LoC probably would be an interesting experience that I won't encounter.
- kqr 7y ago
  It sounds like you have only ever worked alone or with incompetent teams. I strongly recommend at least trying to work in a team of smart people with more experience than you. It can be an enlightening experience. There's a chance you will learn - how to handle criticism professionally; - that you actually write more buggy code than you think; - that there are a lot of critiques that are not subjective that you simply currently cannot imagine (because if you could, you wouldn't get it wrong in the first place, right?); and - there are some subjective opinions which you didn't know about but agree with once you do.
harshalizee 7y ago
Mainly because the code that is written in organizations is meant to be easily read and traversed through by other developers. Every place I've worked at had different standards on how to to something not because it was superior but because it is predictable.
deleted 7y ago
[deleted]

by dpcan 7y ago

SahAssar 7y ago

I think we put up with it because personal development requires outside feedback. I couldn't imagine getting better at the pace I am without both having to justify and explain my decisions to others. I don't understand your viewpoint at all. The best part about coding for me is getting a review with a lot of interesting comments about how it could be done differently. It jogs my brain down paths I would never have seen by myself.

kareemm 7y ago
As a consultant (not the OP) one of the best parts of writing code is having it solve real business problems (and getting paid well for it). It's a point of personal pride to write reasonably good code, but the structure doesn't matter to the person paying the bills - the outcome does. It's like living in a house: as long as it doesn't fall down and doesn't cost unreasonable amounts to maintain, I don't really care about how well-formed the mortar is, or that the drywall is hung perfectly according to company standards. I just want to live in the house and not worry about it.
- SahAssar 7y ago
  Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not you you are imposing a single persons idea of what the business problem is and how it should be solved on the maintainer, which they might not agree with * Personal development depends on realizing when you are wrong or have used the wrong tool. If nobody challenges your decisions you will probably not realize that as often (or at all) and therefore not improve as much. * Solving business problems means solving problems for a business. Usually businesses evolve over time, so the business problems might change. Who will understand the code in that case? How do you know the code is understandable to other people if nobody else reviewed it? And as for the house example: before buying that house I would definitely hire somebody else to check it, and that is legally required in some countries. I don't trust anyone to rate their own work. In this case the person who hired your consultancy bought the house, and they should definitely have an expert that did not build it check it. --- Just a FYI: I'm also a consultant, but work on a project where we have discussions about how to structure the code and do code reviews and so on.
  - kareemm 7y ago
    Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.
- dwild 7y ago
  The structure does have an impact on its maintainability though. You said you don't care about well-formed the mortar is or how the drywall is hung, but would you care if it was made in a way that would make it much harder later on to run new wires inside the wall? I would care personnaly. > writing code is having it solve real business problems Sure, but writing good code is about solving future problem the business is going to have too. A problem has more than a single dimension. If your code will never evolve, if it's a definitive solution to their problems, the structure doesn't matter that's true, but sadly, that's almost never the case.
- alfalfasprout 7y ago
  It's like building someone a house where the design is flawed and someday it'll fall down and kill everyone. By the time it happens, you'll be long gone. Doesn't mean it's the right thing to do.
- dragonwriter 7y ago
  > the structure doesn't matter to the person paying the bills - the outcome does. The structure matters to the outcome; but the outcome problems of bad structure tend to manifest after paid-by-engagement contractors have left.
vbezhenar 7y ago
> personal development requires outside feedback Is it true? If I read book or blog, I improve my skills. Sure, feedback helps but I don't think that it's a hard requirement.
- SuperFerret 7y ago
  I would challenge you to find a profession that doesn't benefit greatly from peer review and feedback.
- throwaway894345 7y ago
  In my personal experience, reading alone is less efficient by at least 1 order of magnitude.
- hombre_fatal 7y ago
  I don't think anything is quite as effective as having a conversation with others. It challenges you in a deep, possibly mind-changing way that a book cannot. I didn't quite realize this until, after 5 years of building things on my own, I had a co-founder. I feel like I gained 10 years of experience just from working with him and having to explain my solutions or why I didn't consider this other one, or having to realize that I was in fact wrong. That's a hard pill to swallow when you've only worked with books. Craftsmanship is more than just learning new things. Sometimes you need to have your entire model of what's best swapped out for new ideas, like society realizing a republic is better than feudalism, than never evolving past your original position.
- kqr 7y ago
  The steel man of that argument is that yes, with no feedback you have nothing to evaluate your decisions against, and all feedback is outside feedback. That said, I think the person you're responding to meant outside feedback as in opinions from peers, which I agree is very powerful, but not strictly necessary.
jariel 7y ago
"because personal development " 2) standard practices, idioms, consistency. You can't use tabs if the entire company uses spaces or use Python if it's a Java shop. 3) Because in most cases, an extra set of eyes can help provide real, material constructive feedback. I have little trust that any standalone developer is going to just write 'solid code'. Who has that level of self-awareness to recognize they are 'that good', let alone actually be good without help? It's a basic matter of professionalism to work with others and to be good team members, without it, we're not going to get much done. For smaller projects with very clear requirements, it matters less.
austincheney 7y ago
For me, as a developer who maintains open source software, the best feedback has nothing to do with the code. Honestly, nobody cares. The application does what it claims or it doesn't. People who spend all their energy on code style have clearly, in my opinion, never had the experience of directly interfacing with their users. Here is my checklist of competence: * defects - The application has certain defects or it doesn't and you can prove it with tests. If there is a defect I will prioritize it, or solve it immediately, or mark it as won't fix. * performance - Does the application execute fast enough in all stages and interactions? This is a simple yes or no, but performance testing is often volatile so this needs to be tested and measured as well so that it can be observed over time keeping slippage in mind. * ease of use - Does the application work out of the box? If not its broken. If it requires a bunch of manual configuration then nobody will use unless its forced on them. For this I take all my frustrations with corporate software from my past jobs and I intentionally design against that when I write software and encourage my users to complain to me. * documentation - Does the documentation stand on its own? Is it complete, well organized, and simple enough that a high school freshman can read it? If you cannot write you aren't as great a developer as you think you are.
- croo 7y ago
  > Honestly, nobody cares Other programmers care. A one/two man workshop doesn't need order or processes to get things done. A ten man workshop cannot function without it. The same is true with coding - it becomes a tool for programmers to communicate intent, it's becomes important to be ordered, clean and understandable by every other dev.
  - austincheney 7y ago
    The end users of my open source software are all developers and they never complained about the code style. Not once. My largest application lived for 10 years and was used by hundreds of thousands of people. > it's becomes important to be ordered, clean and understandable by every other dev Code style is the wrong tool for that job. Better are code reviews and written documentation.
- 7y ago
winrid 7y ago
Maybe this person is just against nitpicking..?
P_I_Staker 7y ago
Not to mention you need teams to solve larger problems and/or support more customers. So OP's comment basically amounts to a cruel boast about the BS he doesn't have to put up with. It'd be like telling a construction worker taking a water break: "That's the nice thing about the office jobs. No need to worry about hydration because I'm not out in the hot sun all day." I have a feeling this kind of observation would not be well received.
dpcan 7y ago
Yeah, I don't really need that. I like to learn to do new things, and my passion is coding and tinkering with projects and learning new tech, so I have no problem finding my way down new avenues of doing things. It's the petty stuff that I hate. I did work somewhere during the dot-com years and we had an entire meeting about double spacing. Whether we press enter TWICE after an if-statement bracket, or once. I hated every second of it.

daenz 7y ago

Do you not see value in more experienced people giving you feedback on how to tackle a problem better?

johnchristopher 7y ago

> I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever. It really depends on the industry your work with, code base size and number of contributors.

johnchristopher 7y ago

> I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever Yeah, but they usually have loaded guns to our head so we tend to comply. Jeez.

ben509 7y ago

Working a similar number of years in various corporate jobs, I haven't seen too much of that, but it does happen. I'm probably my harshest critic when I'm looking at code I wrote years ago. Or maybe someone is cursing me after I've moved on. I wonder, you've never been critiqued, but how many times have you gotten a project and had to unravel badly written code? I think the macro-style issues people debate are mostly about code that is being maintained and reworked over and over again in a product with a long life. > I'd go nuts if someone told me I had to use more classes, or a certain language, or tabs over spaces, or whatever. Those issues all have root causes you must have dealt with. Tabs vs. spaces type stuff is mostly about keeping diffs clean in a repo. Language choice is just a matter of components being able to work together, and being able to hire people who can work on it. And choices like "more classes" are usually revolving around testability of code. > I don't know how you guys put up with it Absolutely, maintaining a product over a long period of time can be exhausting. I think there are benefits to it, though. It's extremely gratifying when you've written something that someone else builds on and they actually get the structure and their new code fits in very closely to how you intended. The whole thing kind of becomes your baby, albeit a baby that you're thinking, "one of these days I'm going to cut her head off and stitch a new one on and she'll be way cuter."

pixelbash 7y ago

I was in this boat for 8 years or so before starting a company and hiring a second developer. I lucked out and got a highly research driven one to learn from, and I gotta say I've learned a ton in 2 years. Even if it's harder in some ways than being solo, I think it's been worth it to have that pressure to improve code and processes. I was kind of coasting before if I'm honest, even though I felt like I was really good at my job.

alexbanks 7y ago

This sounds like a dangerous mindset. "I don't ever want to even hear about it if what I'm doing is ridiculous". I am not attacking you or saying that what you're doing is wrong, I'm just curious/cautious about the motives behind not wanting to know if there are better/more productive ways of doing things that you just might not know about? Collaboration is usually a very good thing, in spite of the small % of terrible teammates you occasionally get.

therealx 7y ago
It depends on the person. Not everyone needs code review to strive for better and know when you're doing poorly. Collaboration is an easy way to get that, but it's not required. The same people that have the personality to learn things on their own often are the same that will improve their code over time without someone else.

gmanley 7y ago

Different perspectives help you grow. I can't imagine not getting feedback. We aren't ridiculed about code structure but given feedback that you can take, or not, with a discussion. It seems pretty problematic that getting feedback would make you "go nuts". Obviously this depends on the organization but, most of the time, I'm not talking about superficial stuff, like tabs over space, but legitimate changes that can improve my code. No one writes nothing but perfect code and having someone double check you can be immensely valuable.

vbezhenar 7y ago

I'm in a similar boat. When I started programming, I always was the smartest guy in the company so I never had a chance to improve from feedback. Last years I'm alone as a programmer and I love it. If someone would criticize my code, that probably would make be very unhappy and I probably will fight that, because every critique I can imagine will be based on subjective factors (of course bugs are objective, but I don't usually write buggy code). I guess, some people just better left alone as long as they can find someone ready to pay them. The downside is that I can't really write big projects. My biggest projects are few dozens of thousands of LoC and typical project is few thousands of LoC. They are pretty useful to end-users, though, but participating in some huge project with millions LoC probably would be an interesting experience that I won't encounter.

kqr 7y ago
It sounds like you have only ever worked alone or with incompetent teams. I strongly recommend at least trying to work in a team of smart people with more experience than you. It can be an enlightening experience. There's a chance you will learn - how to handle criticism professionally; - that you actually write more buggy code than you think; - that there are a lot of critiques that are not subjective that you simply currently cannot imagine (because if you could, you wouldn't get it wrong in the first place, right?); and - there are some subjective opinions which you didn't know about but agree with once you do.

harshalizee 7y ago

Mainly because the code that is written in organizations is meant to be easily read and traversed through by other developers. Every place I've worked at had different standards on how to to something not because it was superior but because it is predictable.

deleted 7y ago

[deleted]