14 ms·

You usually hear it in the context of someone who's had a long enough career to forget how hard "just writing code" is when you're a noob ;)

bitexploder 4y ago
Also, software is ultimately written by humans, for humans. A very overlooked thing in many circles. It seems so simple, but folks off in the deeply technical universe of engineering should remember it.
- scythe 4y ago
  In short, writing code is communicating with people! Often, the listener is future you.
- ehnto 4y ago
  Maybe this is why infrastructure as code feels so obtuse to me, there isn't many opportunities to explain yourself in the code and so most of the communication is done in the docs. Perhaps there is an opportunity for a more natural language approach to infrastructure as code, but I am not sure how far you can take that since the reality is still a lot of arbitrary delcarations.
  - tempay 4y ago
    I think a lot of the infrastructure-as-code motivation comes from struggling with documentation. At least it provides a unambiguous source of truth which is going to be correct. Understanding it and it’s quirks can be tedious but it’s better than port scanning and guessing hostnames to figure out what infrastructure exists.
  - tuukkah 4y ago
    > there isn't many opportunities to explain yourself in the code Can't you include comments in your code?
    - ehnto 4y ago
      I've never seen it done in infrastructure as code files, but I probably would if I were writing it. Or I'd at least include some explanation in the readme.
      - rmetzler 4y ago
        I do it all the time in YAML config and HCL, especially stuff which is not obvious. That's the main benefit of YAML over JSON, to be able to communicate to human readers through comments. Some stuff, like which CIDRs are necessary for which connection, are only obvious in the moment you write it, not 1 or 2 years later or for another person who joins your project next week.
  - mellavora 4y ago
    I doubt a "natural language" approach would work; the natural language for the domain has to be very precise. Just like the "natural language" for software has to be similar to either C or LISP. You are giving precise technical instructions which will be run by a machine. "Hey, just spin up a server with enough capacity, alright?" Yes, sure. Please define capacity. Those definitions are usually in the docs, which is why the code makes so many references to the docs. Many infra-as-code systems allow you to add comments to the docs, which (if done well) can really help. And infra-as-code is much superior to infra-as-let's-click-on-the-gui-until-it-works' Yes, it is hard to read (I know, I do it for a living). But at least you have a document which describes the infra!
  - mellavora 4y ago
    Better answer, thanks to Hume: “It is very difficult to talk of the operations of the mind with perfect propriety and exactness; because common language has seldom made any very nice distinctions among them, but has generally call’d by the same term all such as nearly resemble each other. And as this is a source almost inevitable of obscurity and confusion in the author; so it may frequently give rise to doubts and objections in the reader, which otherwise he wou’d never have dream’d of.” ––A Treatise of Human Nature, by David Hume, pg. 76
- bluetomcat 4y ago
  Software is written by humans for solving a new problem with new constraints and requirements. Code being understandable to other humans is a desirable side-effect, but in no way primary. Some problems are inherently hard and few humans have the capacity to reason about them, no matter how nicely-formatted, modularised and linted your code is.
  - flyinglizard 4y ago
    All the more reason not to make it any more complicated than necessary (even if it's in the expense of some code elegance). Not just for other people, but also for the future you, coming to maintain this. Going back to your code after three years, and someone else approaching the code for the first time are not that much different. Also this is why I love automation, like scripts for everything. It's like a memo to your future self, with the side benefit of sparing you menial work. I keep even single one liner commands as their own shell scripts with a descriptive name. Try to read and understand everything your write. If it doesn't click immediately or needs too much outside context or "working memory", make it simpler. Failing that, elaborate in comments.
    - bluetomcat 4y ago
      Sometimes it has to be complicated. Complication in one area (usually infrastructure code) enables simplicity in other areas (usually application code). An OS memory manager deals with the complexity of page management, so as to present the nice abstraction of an orderly address space to applications. An SQL query optimiser is complex in order to allow dumb and "understandable" queries from applications.
  - bitexploder 4y ago
    It isn’t just about code. It’s about the software’s user. Humans and the programming is one part. But the software is for people. The problems being solved are for people. It is humans all the way down. In this way I view software as a very humanistic domain. That is why the theme of communication angle resonates with me so much. Agile is misused a lot but for goodness sake, talk to your users. Even if your user is just you. This is exactly the thinking I see people trapped in and was pointing out. Focused on solving the engineering problems, not the humans that come before and after the problem (both end users and developers). We know there are hard things in engineering and problem solving ain’t easy. I think in an absolute sense you are right, but in a practical sense, it is more than a desirable side effect. Code once written and solving a problem can live on for a very ling time.
malux85 4y ago
Yeah this is it - Unconscious incompetent - you don’t even know how much you don’t know Consciously incompetent - you have a rough idea of how much you still have to learn Consciously competent - with willpower and effort you are competent at your job Unconsciously competent - you are competent at writing code without effort or even thinking about it Senior engineers (good ones) become unconsciously competent, and forget how difficult it is to write good code - because it’s now automatic!
- ehnto 4y ago
  I recommend any senior engineer look for opportunities to mentor, it keeps your awareness sharp and you may even encounter some unique perspectives that challenge your current model.
  - travisgriggs 4y ago
    I have been surprised/hurt at the lack of these opportunities. I make myself very available to interns, sometimes, we stumble on great discussions, but they insist on doing it all on their own. People closer to my cohort often reach out for mentoring. I don’t know if it’s an ageism thing, or I’m just an asshole and I can’t see it, or what. I’ve decided to quit trying so hard to “give to the following generation”. I’m glad to share, but it’s not worth my own sense of “not mattering anymore.”
    - ehnto 4y ago
      Other industries definitely have it better in regards to mentorship and passing the torch on so to speak. I've not once seen an apprenticeship style program for software developers, even though it's the perfect industry for it. There's not really a graceful ageing out process for the industry either. It seems the only pathways are moving up into management. At that point, often your software engineering knowledge gets put to the side, and new developers don't get access to it. I've worked a few times with people I thought were just leadership jockeys their whole career, and then it turns out they were actually software developers for 20 years prior to that. They had all pretty much washed their hands of software, and their attitude was "Well, what would I know now. Not really my scene anymore.". That's a lot of experience thrown out the window.
intelVISA 4y ago
I really worry how out of touch I am on that front. It pains me but I offer such limited value to jrs as a result :( All tech is magic until you pull the curtain...
pjmlp 4y ago
Or we realized that pretty code, or whatever is the current fad in how to write code, doesn't matter if it isn't actually solving the problem that the end users care about. A problem that one will only properly learn about by communicating with other humans, understanding their expectations, skillset and most relevant, what their business domain is all about.
fjfaase 4y ago
I still find coding a mentally exhausting task and maybe even more now that I am getting older. I find it harder to concentrate and I am more easily distracted. It often takes me time to get in the right mood to code. I guess my memory skills are probably also getting worse. I suffer a lot from procrastination and I think one of the reasons is that I find it still a hard to write code. Which most of the time is not coding but reading and trying to understand code. And thinking about all the alternative ways to solve a problem. I often find myself struggling to commit my changes doubting whether my changes are good. I also still find myself looking up the order of the parameters of standard C library functions that I have used over 30 years. I am dyslectic and struggle to remember facts. I also still find myself making stupid Boolean logic coding errors and make one-off mistakes. I still find myself stepping through loops with the debugger just to see if I did not make a stupid mistake. It still often takes me more time to solve an issue than I had thought it would take me. There are days when I leave the office feeling that I have accomplished nothing because I have not committed any working code.
- Hedepig 4y ago
  > I still find coding a mentally exhausting task and maybe even more now that I am getting older If it helps, we're at the dawn of AI assisted development. That will take a lot of the cognitive burden, allowing us to focus on the "what" more than the "how"
  - P5fRxh5kUvp2th 4y ago
    I doubt it, the design of the code is much more important and that hasn't been solved by AI yet.
    - deleted 4y ago
      [deleted]
    - Hedepig 4y ago
      Reducing cognative load is still entirely helpful I predict AI assisted archicture design will come soon
treeman79 4y ago
Have a stroke. Then have to relearn programming again. Bloody shocking just how many layers of concepts, frame works, Etc there is. Or step away from JavaScript world for a couple of years. About the same sensation.

bitexploder 4y ago

Also, software is ultimately written by humans, for humans. A very overlooked thing in many circles. It seems so simple, but folks off in the deeply technical universe of engineering should remember it.

scythe 4y ago
In short, writing code is communicating with people! Often, the listener is future you.
ehnto 4y ago
Maybe this is why infrastructure as code feels so obtuse to me, there isn't many opportunities to explain yourself in the code and so most of the communication is done in the docs. Perhaps there is an opportunity for a more natural language approach to infrastructure as code, but I am not sure how far you can take that since the reality is still a lot of arbitrary delcarations.
- tempay 4y ago
  I think a lot of the infrastructure-as-code motivation comes from struggling with documentation. At least it provides a unambiguous source of truth which is going to be correct. Understanding it and it’s quirks can be tedious but it’s better than port scanning and guessing hostnames to figure out what infrastructure exists.
- tuukkah 4y ago
  > there isn't many opportunities to explain yourself in the code Can't you include comments in your code?
  - ehnto 4y ago
    I've never seen it done in infrastructure as code files, but I probably would if I were writing it. Or I'd at least include some explanation in the readme.
    - rmetzler 4y ago
      I do it all the time in YAML config and HCL, especially stuff which is not obvious. That's the main benefit of YAML over JSON, to be able to communicate to human readers through comments. Some stuff, like which CIDRs are necessary for which connection, are only obvious in the moment you write it, not 1 or 2 years later or for another person who joins your project next week.
- mellavora 4y ago
  I doubt a "natural language" approach would work; the natural language for the domain has to be very precise. Just like the "natural language" for software has to be similar to either C or LISP. You are giving precise technical instructions which will be run by a machine. "Hey, just spin up a server with enough capacity, alright?" Yes, sure. Please define capacity. Those definitions are usually in the docs, which is why the code makes so many references to the docs. Many infra-as-code systems allow you to add comments to the docs, which (if done well) can really help. And infra-as-code is much superior to infra-as-let's-click-on-the-gui-until-it-works' Yes, it is hard to read (I know, I do it for a living). But at least you have a document which describes the infra!
- mellavora 4y ago
  Better answer, thanks to Hume: “It is very difficult to talk of the operations of the mind with perfect propriety and exactness; because common language has seldom made any very nice distinctions among them, but has generally call’d by the same term all such as nearly resemble each other. And as this is a source almost inevitable of obscurity and confusion in the author; so it may frequently give rise to doubts and objections in the reader, which otherwise he wou’d never have dream’d of.” ––A Treatise of Human Nature, by David Hume, pg. 76
bluetomcat 4y ago
Software is written by humans for solving a new problem with new constraints and requirements. Code being understandable to other humans is a desirable side-effect, but in no way primary. Some problems are inherently hard and few humans have the capacity to reason about them, no matter how nicely-formatted, modularised and linted your code is.
- flyinglizard 4y ago
  All the more reason not to make it any more complicated than necessary (even if it's in the expense of some code elegance). Not just for other people, but also for the future you, coming to maintain this. Going back to your code after three years, and someone else approaching the code for the first time are not that much different. Also this is why I love automation, like scripts for everything. It's like a memo to your future self, with the side benefit of sparing you menial work. I keep even single one liner commands as their own shell scripts with a descriptive name. Try to read and understand everything your write. If it doesn't click immediately or needs too much outside context or "working memory", make it simpler. Failing that, elaborate in comments.
  - bluetomcat 4y ago
    Sometimes it has to be complicated. Complication in one area (usually infrastructure code) enables simplicity in other areas (usually application code). An OS memory manager deals with the complexity of page management, so as to present the nice abstraction of an orderly address space to applications. An SQL query optimiser is complex in order to allow dumb and "understandable" queries from applications.
- bitexploder 4y ago
  It isn’t just about code. It’s about the software’s user. Humans and the programming is one part. But the software is for people. The problems being solved are for people. It is humans all the way down. In this way I view software as a very humanistic domain. That is why the theme of communication angle resonates with me so much. Agile is misused a lot but for goodness sake, talk to your users. Even if your user is just you. This is exactly the thinking I see people trapped in and was pointing out. Focused on solving the engineering problems, not the humans that come before and after the problem (both end users and developers). We know there are hard things in engineering and problem solving ain’t easy. I think in an absolute sense you are right, but in a practical sense, it is more than a desirable side effect. Code once written and solving a problem can live on for a very ling time.

malux85 4y ago

Yeah this is it - Unconscious incompetent - you don’t even know how much you don’t know Consciously incompetent - you have a rough idea of how much you still have to learn Consciously competent - with willpower and effort you are competent at your job Unconsciously competent - you are competent at writing code without effort or even thinking about it Senior engineers (good ones) become unconsciously competent, and forget how difficult it is to write good code - because it’s now automatic!

ehnto 4y ago
I recommend any senior engineer look for opportunities to mentor, it keeps your awareness sharp and you may even encounter some unique perspectives that challenge your current model.
- travisgriggs 4y ago
  I have been surprised/hurt at the lack of these opportunities. I make myself very available to interns, sometimes, we stumble on great discussions, but they insist on doing it all on their own. People closer to my cohort often reach out for mentoring. I don’t know if it’s an ageism thing, or I’m just an asshole and I can’t see it, or what. I’ve decided to quit trying so hard to “give to the following generation”. I’m glad to share, but it’s not worth my own sense of “not mattering anymore.”
  - ehnto 4y ago
    Other industries definitely have it better in regards to mentorship and passing the torch on so to speak. I've not once seen an apprenticeship style program for software developers, even though it's the perfect industry for it. There's not really a graceful ageing out process for the industry either. It seems the only pathways are moving up into management. At that point, often your software engineering knowledge gets put to the side, and new developers don't get access to it. I've worked a few times with people I thought were just leadership jockeys their whole career, and then it turns out they were actually software developers for 20 years prior to that. They had all pretty much washed their hands of software, and their attitude was "Well, what would I know now. Not really my scene anymore.". That's a lot of experience thrown out the window.

intelVISA 4y ago

I really worry how out of touch I am on that front. It pains me but I offer such limited value to jrs as a result :( All tech is magic until you pull the curtain...

pjmlp 4y ago

Or we realized that pretty code, or whatever is the current fad in how to write code, doesn't matter if it isn't actually solving the problem that the end users care about. A problem that one will only properly learn about by communicating with other humans, understanding their expectations, skillset and most relevant, what their business domain is all about.

fjfaase 4y ago

I still find coding a mentally exhausting task and maybe even more now that I am getting older. I find it harder to concentrate and I am more easily distracted. It often takes me time to get in the right mood to code. I guess my memory skills are probably also getting worse. I suffer a lot from procrastination and I think one of the reasons is that I find it still a hard to write code. Which most of the time is not coding but reading and trying to understand code. And thinking about all the alternative ways to solve a problem. I often find myself struggling to commit my changes doubting whether my changes are good. I also still find myself looking up the order of the parameters of standard C library functions that I have used over 30 years. I am dyslectic and struggle to remember facts. I also still find myself making stupid Boolean logic coding errors and make one-off mistakes. I still find myself stepping through loops with the debugger just to see if I did not make a stupid mistake. It still often takes me more time to solve an issue than I had thought it would take me. There are days when I leave the office feeling that I have accomplished nothing because I have not committed any working code.

Hedepig 4y ago
> I still find coding a mentally exhausting task and maybe even more now that I am getting older If it helps, we're at the dawn of AI assisted development. That will take a lot of the cognitive burden, allowing us to focus on the "what" more than the "how"
- P5fRxh5kUvp2th 4y ago
  I doubt it, the design of the code is much more important and that hasn't been solved by AI yet.
  - deleted 4y ago
    [deleted]
  - Hedepig 4y ago
    Reducing cognative load is still entirely helpful I predict AI assisted archicture design will come soon

treeman79 4y ago

Have a stroke. Then have to relearn programming again. Bloody shocking just how many layers of concepts, frame works, Etc there is. Or step away from JavaScript world for a couple of years. About the same sensation.