5 ms·

I've found the following really sets apart my programming now vs. earlier in my career: 1. I write and rewrite more now. I view the first time the code works a

I've found the following really sets apart my programming now vs. earlier in my career: 1. I write and rewrite more now. I view the first time the code works as just the first draft (like I would with a paper). Earlier in my career I thought that making it work meant I was done. 2. I spend a lot more time thinking about what's happening in the code and why. I have found some of my best work to happen after days of thinking about small bits of functionality. 3. I get the domain (ie. the big picture) much better. This is insanely valuable and helps me step back. 4. I listen more to opposing views. That's not to say I don't argue my point, but afterwards I spend time to rehash what the other person said when I have no pressure to respond. This guides my thinking a lot as it give me an opportunity to change views/positions. 5. I'm increasingly tolerant of other technologies. I use x, but y must be good too b/c smart people use it. 5.a While I'm more tolerant, I'm less distracted. When I was younger, I spent more time switching technologies to learn "new things". Now I spend more time going deeper on my current stack to learn new things. 6. I now think its ok to write code in a "non optimal" way if it makes it easier for the entire team to work with. I don't believe in writing to the LCD, however I do believe programming just a little above the team's moving average capability is probably better than writing above everyone's head (whether by me or someone better than me).

einhverfr 13y ago
I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time. When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive. Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves. In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well. This being said, I have a few very minor disagreements with you ;-). These may be split hairs though. First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft. What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less. Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess. But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.
- agentultra 13y ago
  > When you are 20 you are pretty much at the height of your mathematical abilities. Is that really true? There are many examples of people who came to mathematics late in life and did good things: http://mathoverflow.net/questions/3591/mathematicians-who-were-late-learners-list http://mathoverflow.net/questions/3591/mathematicians-who-we... I think you only get better with time if you keep yourself sharp. What has changed for me is that I can't sit still and pound back Redbulls for six-hour coding sessions and then hit the gym. My process is also more methodical. But mathematics is certainly one area I've only improved in with time.
  - einhverfr 13y ago
    And also see this: http://www.massey.ac.nz/~rmclachl/overthehill.html http://www.massey.ac.nz/~rmclachl/overthehill.html However, I wonder if there is something else going on here. What I noticed in the list (and in the article I am linking to) is that the early peak seems less obvious from a historiography perspective than it does from a contemporary perspective. So I can't help but wonder if there is a qualitative difference in the sorts of contributions that younger and older mathematicians make. Thinking more in terms of fluid vs crystalized intelligence here, but wondering if there is something else. I know my fluid intelligence is not where it was ten years ago, but part of that is a greater understanding of the problem domain. I can see more possibilities, and I see different ones than I would have before. So I don't think it is as simple as we might want to think but I do think that thinking patterns (and abilities) change qualitatively as we age in ways which are favorable for important contributions when viewed through the light of history. Whether a thesis review board would agree is a different matter.
  - gajomi 13y ago
    >Is that really true? It's almost certainly not true, at least among those that would be called mathematicians. This follows if for no other reason than the fact that it takes years to get up to speed with the forefront of any particular branch of mathematics, which is the prerequisite for testing out one's mathematical abilities (in the context of research). While you occasionally have a few teenage prodigies, most mathematicians won't get started on their career until much later.
collyw 13y ago
> I'm increasingly tolerant of other technologies. I would like to think I am, but recently I have noticed that everyone seems to want to jump on the NoSQL bandwagon. A lot of the jobs I see I would be a good fit want experience using MongoDB (or something similar). I have been looking to learn them, but having read up on the technologies, I can't find a reasonable use case for any of them in my own work. One that would not be equally or better suited to Postgres or MySQL (which I know well). I have come to the conclusion that 90% of people using NoSQL don't actually need it, and are throwing away a lot of useful features just so they can play with the latest fad.
- mercer 13y ago
  Perhaps with age comes increasing tolerance and increasing ability in discerning hypes from useful technologies? I'm a pretty 'young' person, and a much younger programmer, so I can't quite say I got the 'oo shiny lemme use that' thing out of my system, but I'm okay with that (for now it doesn't negatively impact my work, and I learn tons of stuff). But in other areas of life, I've noticed that I generally become less dichotomous in my approach to new and other things, but more discerning too.
- merry-year 13y ago
  NoSQL DBs have real advantages - e.g. you have a huge production relational DB, you want to make schema changes - you have to take your app offline for hours.
  - Denzel 13y ago
    No. You can migrate big production relational DBs with much less than hours of downtime; sometimes there's no downtime at all. Please, either qualify your statement, or stop speaking in such an absolute sense.
    - spiffytech 13y ago
      Would you mind expanding on how to minimize downtime when applying migrations to large DBs? It's clear the grandparent isn't familiar enough with the relevant techniques to realize their statement needed qualification, or could count as "nonsense", so they could probably benefit from the explanation.

einhverfr 13y ago

I hate to sound like an old fogie here (I am almost 40) but one thing that occurs to me is that as we age our thinking changes and all the things you mention often develop over time. When you are 20 you are pretty much at the height of your mathematical abilities. This is fine for certain kinds of programming, but it is not really ideal for others. It ensures that algorithms primary and the domains in a real sense become secondary. As you get older, these tend to flip. You understand the domains better and may not be quite as good at generating optimal algorithms, but the tradeoff is generally positive. Additionally I think there is a tradeoff that happens between dreaming of building great things and developing a craftsmenship approach to the small things. Engineer the small pieces well, and the big pieces will take care of themselves. In most areas, I think one is better with a very mixed-age and mixed-experience team. Older, more experienced programmers bring something very special to the table, but the same is true for younger programmers as well. This being said, I have a few very minor disagreements with you ;-). These may be split hairs though. First, while I rewrite more in some ways, I actually find on the whole I rewrite less because I am not afraid to procrastinate while trying to understand the domain. People wonder why my code seems to come out fully formed and it is because I am not afraid to spend my time thinking about the problem instead of writing a rough draft. What has changed is the sort of rewrites I do. I will typically re-engineer a small piece to remove cruft based on lessons learned from the last two years, rather than rewriting a big piece to meet a new requirement (because things tend to be designed more extensably now). So I am less afraid to rewrite and more willing to do so, but at the same time, I tend to rewrite less. Finally there is the question of optimal way to program. I am of the opinion (probably in part because of how much work I do with Perl) that there is no singular optimal way. Optimal has to be globally defined and one of the jobs of the engineer is to ensure that the framework is optimal so that the team can program optimally. If the team is not part of the definition of what is optimal, then I do agree it is a mess. But I don't think we are dealing with a single dimension here. Understanding the problems the team is struggling with is a good way to ensure that framework can be built in a way that drives that average capability up.

agentultra 13y ago
> When you are 20 you are pretty much at the height of your mathematical abilities. Is that really true? There are many examples of people who came to mathematics late in life and did good things: http://mathoverflow.net/questions/3591/mathematicians-who-were-late-learners-list http://mathoverflow.net/questions/3591/mathematicians-who-we... I think you only get better with time if you keep yourself sharp. What has changed for me is that I can't sit still and pound back Redbulls for six-hour coding sessions and then hit the gym. My process is also more methodical. But mathematics is certainly one area I've only improved in with time.
- einhverfr 13y ago
  And also see this: http://www.massey.ac.nz/~rmclachl/overthehill.html http://www.massey.ac.nz/~rmclachl/overthehill.html However, I wonder if there is something else going on here. What I noticed in the list (and in the article I am linking to) is that the early peak seems less obvious from a historiography perspective than it does from a contemporary perspective. So I can't help but wonder if there is a qualitative difference in the sorts of contributions that younger and older mathematicians make. Thinking more in terms of fluid vs crystalized intelligence here, but wondering if there is something else. I know my fluid intelligence is not where it was ten years ago, but part of that is a greater understanding of the problem domain. I can see more possibilities, and I see different ones than I would have before. So I don't think it is as simple as we might want to think but I do think that thinking patterns (and abilities) change qualitatively as we age in ways which are favorable for important contributions when viewed through the light of history. Whether a thesis review board would agree is a different matter.
- gajomi 13y ago
  >Is that really true? It's almost certainly not true, at least among those that would be called mathematicians. This follows if for no other reason than the fact that it takes years to get up to speed with the forefront of any particular branch of mathematics, which is the prerequisite for testing out one's mathematical abilities (in the context of research). While you occasionally have a few teenage prodigies, most mathematicians won't get started on their career until much later.

collyw 13y ago

> I'm increasingly tolerant of other technologies. I would like to think I am, but recently I have noticed that everyone seems to want to jump on the NoSQL bandwagon. A lot of the jobs I see I would be a good fit want experience using MongoDB (or something similar). I have been looking to learn them, but having read up on the technologies, I can't find a reasonable use case for any of them in my own work. One that would not be equally or better suited to Postgres or MySQL (which I know well). I have come to the conclusion that 90% of people using NoSQL don't actually need it, and are throwing away a lot of useful features just so they can play with the latest fad.

mercer 13y ago
Perhaps with age comes increasing tolerance and increasing ability in discerning hypes from useful technologies? I'm a pretty 'young' person, and a much younger programmer, so I can't quite say I got the 'oo shiny lemme use that' thing out of my system, but I'm okay with that (for now it doesn't negatively impact my work, and I learn tons of stuff). But in other areas of life, I've noticed that I generally become less dichotomous in my approach to new and other things, but more discerning too.
merry-year 13y ago
NoSQL DBs have real advantages - e.g. you have a huge production relational DB, you want to make schema changes - you have to take your app offline for hours.
- Denzel 13y ago
  No. You can migrate big production relational DBs with much less than hours of downtime; sometimes there's no downtime at all. Please, either qualify your statement, or stop speaking in such an absolute sense.
  - spiffytech 13y ago
    Would you mind expanding on how to minimize downtime when applying migrations to large DBs? It's clear the grandparent isn't familiar enough with the relevant techniques to realize their statement needed qualification, or could count as "nonsense", so they could probably benefit from the explanation.