6 ms·

> Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they unders

> Highly talented developers don't need this structure and process, but if given the freedom, they are also more likely to create software that only they understand, using flavor-of-the-month languages or frameworks that they have personally selected. I think you might be using a slightly incomplete definition of “highly talented.” My highly talented colleagues take maintainability and minimizing tech debt into account when making technical contributions.

ChrisMarshallNY 4y ago
I do, and I consider myself "highly-talented," as well as "extremely experienced" (over 30 years of software development -shipping- experience). I'm also an excellent "team player." I worked for a Japanese corporation for almost 27 years, and you don't last long at Japanese companies, if you don't "team" well. But I also don't shy from using advanced techniques; usually in language idioms, as opposed to ungrokkable algorithms. Most of my algorithms are fairly basic. I tend to go after difficult problems, though, and it's ... difficult ... to solve difficult problems, simply. Sometimes, I have beautiful, low-code solutions, sometimes, I have solutions that would send Rube Goldberg into fits. They all work, though; and they ship. I expect the folks that maintain my code (usually Yours Troolie) to be at a level similar to mine, and I won't "dumb down" my code, so someone fresh out of a JS bootcamp can understand it. I have an insane level of documentation, and supporting artifacts. If someone is able to understand the code, they will get a lot of help. I'm militant about Quality. My code needs to work well, be performant, be flexible, and to have clear, unambiguous boundaries. A great deal of my work consists of reusable, standalone packages (I use them heavily, in my projects; Most of my dependencies are ones that I wrote). This affords an intense level of Quality. It's abstraction with teeth. I'm used to owning the entire project lifecycle, from napkin sketch, to shrinkwrap. This gives me a great deal of insight into what is necessary for "the long game," without getting caught up in "bikeshedding." My experience is that most companies that I've encountered, don't want people like me, working for them, so you get what you get.
oblio 4y ago
How often are they around 2 years later, though?
- ChrisMarshallNY 4y ago
  I've written SDKs and infrastructure software that has lasted decades. The secret is usually to use boring tech, and inline documentation.
  - oblio 4y ago
    I meant the devs, not the software :-))
    - ChrisMarshallNY 4y ago
      This is true. I think it's a huge problem, but everyone seems to be happy with the situation, so what do I know?

ChrisMarshallNY 4y ago

I do, and I consider myself "highly-talented," as well as "extremely experienced" (over 30 years of software development -shipping- experience). I'm also an excellent "team player." I worked for a Japanese corporation for almost 27 years, and you don't last long at Japanese companies, if you don't "team" well. But I also don't shy from using advanced techniques; usually in language idioms, as opposed to ungrokkable algorithms. Most of my algorithms are fairly basic. I tend to go after difficult problems, though, and it's ... difficult ... to solve difficult problems, simply. Sometimes, I have beautiful, low-code solutions, sometimes, I have solutions that would send Rube Goldberg into fits. They all work, though; and they ship. I expect the folks that maintain my code (usually Yours Troolie) to be at a level similar to mine, and I won't "dumb down" my code, so someone fresh out of a JS bootcamp can understand it. I have an insane level of documentation, and supporting artifacts. If someone is able to understand the code, they will get a lot of help. I'm militant about Quality. My code needs to work well, be performant, be flexible, and to have clear, unambiguous boundaries. A great deal of my work consists of reusable, standalone packages (I use them heavily, in my projects; Most of my dependencies are ones that I wrote). This affords an intense level of Quality. It's abstraction with teeth. I'm used to owning the entire project lifecycle, from napkin sketch, to shrinkwrap. This gives me a great deal of insight into what is necessary for "the long game," without getting caught up in "bikeshedding." My experience is that most companies that I've encountered, don't want people like me, working for them, so you get what you get.

oblio 4y ago

How often are they around 2 years later, though?

ChrisMarshallNY 4y ago
I've written SDKs and infrastructure software that has lasted decades. The secret is usually to use boring tech, and inline documentation.
- oblio 4y ago
  I meant the devs, not the software :-))
  - ChrisMarshallNY 4y ago
    This is true. I think it's a huge problem, but everyone seems to be happy with the situation, so what do I know?