3 ms·

"The important part is to understand what a paradigm is good at and what it is not, and select the right one for whatever you are working on." I've been progra

by jadbox 6y ago

"The important part is to understand what a paradigm is good at and what it is not, and select the right one for whatever you are working on." I've been programming since I was maybe 13, and being 34 today I find this to be more and more true. Programming IS JUST A TOOL to get something done. When I say "just a tool", I do not mean to ~undermine OR overexcite~ the concept of a tool. The real power to seek as a programmer is knowing lots of programming platforms and paradigms, as then you have the knowledge to select the best tool or technique to accomplish solving a specific problem within a domain at hand.

mgkimsal 6y ago
Started at ... 10 and have been doing this for > 35 years in some capacity. Sometimes that 'best tool' really just happens to be the one I have X years of experience in, because I'm here, right now, in front of the project, and have solved the same problem Y times before with acceptable results (systems running, people getting value as expected). That doesn't automatically justify being a stick-in-the-mud and never adopting any new technology ever. But it also means that jumping to new tools on a semi-annual basis, you'll have a hard time having justified confidence you can deliver something of value. I have to qualify with "justified" because... I've seen too many folks who have confidence and... really shouldn't. And I recognize that because I can see how I was once there. I had a call from someone in 2017 asking about something I'd built for them in 2002. System was still running. Someone had been doing basic system upgrades every so often, but they'd hit some logical issues and needed more insight, and pinged me. Last year I noticed a previous client project started in 2000 was still up. I've no doubt they've updated some of the back end stuff, but some of the stuff I put in place I can still see (html comment, semi-unusual url structure, etc). Understanding that what you build might actually be in place, working for people for 15-20 years is hard to get your head around until you've actually done this for 20 years. When I was 20 I could not understand the ramifications of decisions impacting people or companies for 20 years - I just didn't have that life experience - no one at 20 does. We're often fed magical press releases about acquisitions and exits and we read stories of things shutting down, getting sunset, etc. Those aren't the norms though, I don't think. With that in mind, my criteria for choosing the 'right tool' has shifted some in the last few years, and I'm always a bit more hesitant to jump on latest shiny trends, as... I do get somewhat concerned about the long term viability. That has to be a factor in 'best tool' calculations, no? (sorry for long ramble)...
- fendy3002 6y ago
  That's understandable, you learn one tool - hammer at 20, you treat all problem as nail. Screws? Hammer it and lock with duct tape. Later on you learn another tool - screwdriver. Now you see screw, you use screwdriver to tighten it. The problem is it takes years to learn one tool, and it take years to see one case as screws, another as nails, etc. EDIT: OTOH, as you gain more experience, you can classify problem better and look or even develop tools that solve that particular problem. Which is why angular / react / vue is developed and popular.
  - mgkimsal 6y ago
    > The problem is it takes years to learn one tool, Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience. Other things outside the language got better. One was my ability to understand problems and potential solutions (from both technical and business/operations perspectives). Another was the ecosystems around those languages. Best practices, documentation and tooling all evolved to deal with new needs, new hardware, etc. The ability to adapt to those changes and understand the role of the core language/tech in addressing problems is key. Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself - you'll never know every single aspect of everything, so learn to accept that.
    - fendy3002 6y ago
      > Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience. > Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself Exactly in my view, programming language such as PHP and Java isn't tool, they are a set of tools. However the toolset are different between each programming language, let's say that in PHP the hammer has larger head than Java. Let's say that programming features such as iteration (for / while loop) and conditional expression (if) are tools, that can be used to solve specific problems. Well sorry if the analogy or metaphor isn't really accurate...
PaulDavisThe1st 6y ago
Sometimes, the domain has already been chosen ("this application is written in Fortran++"), and your task is to find the best tool/technique given that constraint. This means you cannot necessarily bring your knowledge of Closedjure or Rusty to bear upon the problem even if you believe it would improve the situation.
- mgkimsal 6y ago
  Yes, that happens. One thing I've found that has been helpful is identifying the stuff about idiomatic "language X" that makes it "good", and try to adapt some of those traits to the current situation. I can say as I've moved in and out of other languages and companies/clients/teams, I've been able to identify good habits and behaviors, sometimes those are a result of languages or tooling in different ecosystems. That helps for 'solo' stuff. Trying to introduce those ideas and techniques in existing teams is almost always more difficult than it should be.

by jadbox 6y ago

mgkimsal 6y ago

Started at ... 10 and have been doing this for > 35 years in some capacity. Sometimes that 'best tool' really just happens to be the one I have X years of experience in, because I'm here, right now, in front of the project, and have solved the same problem Y times before with acceptable results (systems running, people getting value as expected). That doesn't automatically justify being a stick-in-the-mud and never adopting any new technology ever. But it also means that jumping to new tools on a semi-annual basis, you'll have a hard time having justified confidence you can deliver something of value. I have to qualify with "justified" because... I've seen too many folks who have confidence and... really shouldn't. And I recognize that because I can see how I was once there. I had a call from someone in 2017 asking about something I'd built for them in 2002. System was still running. Someone had been doing basic system upgrades every so often, but they'd hit some logical issues and needed more insight, and pinged me. Last year I noticed a previous client project started in 2000 was still up. I've no doubt they've updated some of the back end stuff, but some of the stuff I put in place I can still see (html comment, semi-unusual url structure, etc). Understanding that what you build might actually be in place, working for people for 15-20 years is hard to get your head around until you've actually done this for 20 years. When I was 20 I could not understand the ramifications of decisions impacting people or companies for 20 years - I just didn't have that life experience - no one at 20 does. We're often fed magical press releases about acquisitions and exits and we read stories of things shutting down, getting sunset, etc. Those aren't the norms though, I don't think. With that in mind, my criteria for choosing the 'right tool' has shifted some in the last few years, and I'm always a bit more hesitant to jump on latest shiny trends, as... I do get somewhat concerned about the long term viability. That has to be a factor in 'best tool' calculations, no? (sorry for long ramble)...

fendy3002 6y ago
That's understandable, you learn one tool - hammer at 20, you treat all problem as nail. Screws? Hammer it and lock with duct tape. Later on you learn another tool - screwdriver. Now you see screw, you use screwdriver to tighten it. The problem is it takes years to learn one tool, and it take years to see one case as screws, another as nails, etc. EDIT: OTOH, as you gain more experience, you can classify problem better and look or even develop tools that solve that particular problem. Which is why angular / react / vue is developed and popular.
- mgkimsal 6y ago
  > The problem is it takes years to learn one tool, Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience. Other things outside the language got better. One was my ability to understand problems and potential solutions (from both technical and business/operations perspectives). Another was the ecosystems around those languages. Best practices, documentation and tooling all evolved to deal with new needs, new hardware, etc. The ability to adapt to those changes and understand the role of the core language/tech in addressing problems is key. Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself - you'll never know every single aspect of everything, so learn to accept that.
  - fendy3002 6y ago
    > Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience. > Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself Exactly in my view, programming language such as PHP and Java isn't tool, they are a set of tools. However the toolset are different between each programming language, let's say that in PHP the hammer has larger head than Java. Let's say that programming features such as iteration (for / while loop) and conditional expression (if) are tools, that can be used to solve specific problems. Well sorry if the analogy or metaphor isn't really accurate...

PaulDavisThe1st 6y ago

Sometimes, the domain has already been chosen ("this application is written in Fortran++"), and your task is to find the best tool/technique given that constraint. This means you cannot necessarily bring your knowledge of Closedjure or Rusty to bear upon the problem even if you believe it would improve the situation.

mgkimsal 6y ago
Yes, that happens. One thing I've found that has been helpful is identifying the stuff about idiomatic "language X" that makes it "good", and try to adapt some of those traits to the current situation. I can say as I've moved in and out of other languages and companies/clients/teams, I've been able to identify good habits and behaviors, sometimes those are a result of languages or tooling in different ecosystems. That helps for 'solo' stuff. Trying to introduce those ideas and techniques in existing teams is almost always more difficult than it should be.