4 ms·

Would you mind expanding a little bit more, from your perspective, on what falls into tactics and what falls into strategy?

by kornish 10y ago

marklgr 10y ago
In that context, to me, tactics is writing & debugging code, compiling stuff, settings things up to work with other libs--ie. mostly hands-on tasks. Strategy is more about planning, architecture, knowing about the real pros and cons of different solutions eg. libs, tools or languages.
- mattmanser 10y ago
  At 37 I'm much faster at debugging today than I was at 27. And 10 years ago, I was consistently one of the fastest debuggers in a company of 15-20 programmers. Debugging's always been one of my strongest programming skills. So debugging, no, definitely not. I can spot root-causes of bugs now even easier than I used to be able to. And one of the big new skills is that I'm much more able to 'guess' where a bug is in someone else's totally new code-base than I previously was able to. In fact, I also write code faster as I get the general gist of it done much faster first time.
  - marklgr 10y ago
    Some people specialize, and get more and more efficient at the same specific tasks; but I believe it's more common to widen one's experience in various areas (languages, tools, platforms, non-functional requirements etc.), leading to some lack of practice in the hands-on tasks one used to do everyday in the past, and also making it more difficult to commit everything to memory. On the other hand, one generally gets a much broader picture. For instance, I used to be able to perftune UNIX and DB (mostly Oracle on Solaris) pretty well, knowing various kernel parameters by heart and all the tools of the day (tkprof, Cockroft and co). Now I guess I could still get by after some brush-up, but I'm not anywhere near as efficient as I used to be on that specific task. And I still write code, but I don't know every single method of every API anymore. But now, I can design full solutions, from choosing the hardware to setting up platform, languages, monitoring, high-availability, backups, security etc. Not because I'm smarter, but because I've been exposed to all that along the years.
vacri 10y ago
Generally what marklgr said. By tactics, I mean being up to date with the latest lib for -foo- and being on top of what the cool kids are doing, chasing down the rabbit-hole to find that one setting to improve db performance. Individual, almost atomic tasks, especially those in a changing landscape. Strategy is more about planning, forethought, and knowing ahead of time which avenues are worth pursuing and which aren't. As a very simplistic example, a tactician might spend a day down a rabbit-hole and improve a db's performance by a small but significant amount, and a strategist would not have spent that day, knowing that that db is going to be turned off in two weeks. Not the best example, really (and it implies that you're only one or the other, which isn't true at all). There is also overlap between the two. Perhaps a military analogue - tactics is about how to take the forts (shorter timeframes, clearer objectives, obvious goals), and strategy is about determining which forts are worth taking (long-term timeframes, murkier objectives, sometimes unclear goals, concern for secondary effects). The difference is also in scope, I guess. Being a good tactician benefits from energy and focused interest, something which the young'uns tend to have more of (caveat, caveat), and strategy benefits from forethought and experience, something which the old'uns tend to have more of (caveat, caveat, &c)
dagw 10y ago
I've seen several examples where the younger developer (often me) comes up with some really clever code to make a certain thing run really fast, and the older developer coming along and pointing out that my underlying premise is wrong.
matwood 10y ago
Breadth of experience often turns into strategy. Lack of experience tends to show up as when you only have a hammer, every problem looks like a nail. At this point in my career I've written production code in many languages/frameworks and was even a DBA at one point. I've also worked in many types of businesses. Now I can look at a given problem and provide a range of possible solutions. Sometimes those solutions do not involve writing any code at all.

Would you mind expanding a little bit more, from your perspective, on what falls into tactics and what falls into strategy?

by kornish 10y ago

Would you mind expanding a little bit more, from your perspective, on what falls into tactics and what falls into strategy?

marklgr 10y ago

In that context, to me, tactics is writing & debugging code, compiling stuff, settings things up to work with other libs--ie. mostly hands-on tasks. Strategy is more about planning, architecture, knowing about the real pros and cons of different solutions eg. libs, tools or languages.

mattmanser 10y ago
At 37 I'm much faster at debugging today than I was at 27. And 10 years ago, I was consistently one of the fastest debuggers in a company of 15-20 programmers. Debugging's always been one of my strongest programming skills. So debugging, no, definitely not. I can spot root-causes of bugs now even easier than I used to be able to. And one of the big new skills is that I'm much more able to 'guess' where a bug is in someone else's totally new code-base than I previously was able to. In fact, I also write code faster as I get the general gist of it done much faster first time.
- marklgr 10y ago
  Some people specialize, and get more and more efficient at the same specific tasks; but I believe it's more common to widen one's experience in various areas (languages, tools, platforms, non-functional requirements etc.), leading to some lack of practice in the hands-on tasks one used to do everyday in the past, and also making it more difficult to commit everything to memory. On the other hand, one generally gets a much broader picture. For instance, I used to be able to perftune UNIX and DB (mostly Oracle on Solaris) pretty well, knowing various kernel parameters by heart and all the tools of the day (tkprof, Cockroft and co). Now I guess I could still get by after some brush-up, but I'm not anywhere near as efficient as I used to be on that specific task. And I still write code, but I don't know every single method of every API anymore. But now, I can design full solutions, from choosing the hardware to setting up platform, languages, monitoring, high-availability, backups, security etc. Not because I'm smarter, but because I've been exposed to all that along the years.

vacri 10y ago

Generally what marklgr said. By tactics, I mean being up to date with the latest lib for -foo- and being on top of what the cool kids are doing, chasing down the rabbit-hole to find that one setting to improve db performance. Individual, almost atomic tasks, especially those in a changing landscape. Strategy is more about planning, forethought, and knowing ahead of time which avenues are worth pursuing and which aren't. As a very simplistic example, a tactician might spend a day down a rabbit-hole and improve a db's performance by a small but significant amount, and a strategist would not have spent that day, knowing that that db is going to be turned off in two weeks. Not the best example, really (and it implies that you're only one or the other, which isn't true at all). There is also overlap between the two. Perhaps a military analogue - tactics is about how to take the forts (shorter timeframes, clearer objectives, obvious goals), and strategy is about determining which forts are worth taking (long-term timeframes, murkier objectives, sometimes unclear goals, concern for secondary effects). The difference is also in scope, I guess. Being a good tactician benefits from energy and focused interest, something which the young'uns tend to have more of (caveat, caveat), and strategy benefits from forethought and experience, something which the old'uns tend to have more of (caveat, caveat, &c)

dagw 10y ago

I've seen several examples where the younger developer (often me) comes up with some really clever code to make a certain thing run really fast, and the older developer coming along and pointing out that my underlying premise is wrong.

matwood 10y ago

Breadth of experience often turns into strategy. Lack of experience tends to show up as when you only have a hammer, every problem looks like a nail. At this point in my career I've written production code in many languages/frameworks and was even a DBA at one point. I've also worked in many types of businesses. Now I can look at a given problem and provide a range of possible solutions. Sometimes those solutions do not involve writing any code at all.