9 ms·

I once read a quote that was something like "You are only an expert in a given technology when you know when not to use it". Unfortunately I forgot the exact qu

I once read a quote that was something like "You are only an expert in a given technology when you know when not to use it". Unfortunately I forgot the exact quote and the author. (If anyone knows please let me know). This is such a nice quote that speaks a lot about what it means to be an experienced (senior) software engineer. Our field is such a dynamic one! New tools and techniques appear all the time. It's easy to fall into the trap of thinking that newer tools are better. I think this is because in some areas of tech this is almost always true (e.g. hardware). But in software, new tools are techniques are rarely fully better, instead they just provide a different set of trade offs. Progress doesn't follow a linear pattern, it's more like a jagged line slowly trending upwards. We think we are experienced because we know how to use new tools, but in reality we are only more experienced when we understand the trade offs and learn when the tools are really useful and when they are not. A senior engineer knows when not to use micro services, when not to use SQL, when not to use static typing, when not to use React, when not to use Kubernetes, etc. Junior engineers don't know these trade offs, they end up using sophisticated hammers for their screws. It doesn't mean that those hammers are bad or useless, they were just misused.

macspoofing 6y ago
>when not to use static typing I'll bite. When should static typing not be used? (Note: I agree with your general point)
- yashap 6y ago
  When I’m throwing together a quick script, or maybe some minor piece of automation, Python is my go-to language. For any decently large project, though, I prefer static typing.
  - karatestomp 6y ago
    I'd kinda prefer it then, too. If it's short and I'm just scripting stuff up it's probably mostly calls to existing code (libraries) so almost all the static typing would do is tell me when I'm screwing up and give me hints for valid arguments with types and names, with little or no added overhead. It'd be very nice.
    - MaulingMonkey 6y ago
      Consuming types in that context is nice, defining them is what's generally a PITA / extra boilerplate / overhead. To take a concrete example that could go both ways: Say you want to parse a JSON blob for some task. On the one end, you could access it through dynamic typing, or tools like jq, that don't need a schema for the entire data format. At the other extreme, you could make typescript definitions defining a schema for the entire format. The more the same data gets (re)used, the more worthwhile taking the time to define a full schema is. But to download and add type definitions (often out of date and in need of further tweaking) for every once-off API request? Way more effort than it's worth.
      - seer 6y ago
        Most static type systems do not force you to say what’s the entire shape of the data, just what the shape of the data you need is. In fact its a good practice to do in general. So that when processing the json blob you tell what only your processing requires. What you get is that if for example you do your validation, but then by chance you touch more data that you’ve checked for, the types will tell you you are dangerous waters, and you can go update the validations. This is especially useful if you’re not the original author or if you’ve written it several months back and don’t remember the details. Static types are really cool that way, and can be treated as just a faster to write and faster to run and always up to date unit test.
- ergothus 6y ago
  When the communication loss (visual noise) from the added static typing info is of bigger impact than benefit type safety offers you. All of which depends on a lot of variables.
  - hedora 6y ago
    My heuristic is that if anyone else will ever read the code, it should be statically typed (or be written in a language like shell where the language is essentially limited to one type). Most people disagree, but then they end up writing giant python monoliths with layers of implementation inheritance, dependency injection and functional programming paradigms. In the end, they try to port it to pretty much any other language, but at that point it’s too late.
    - empthought 6y ago
      Python has a pretty good type checker.
- jbreiding 6y ago
  For me it's where I'm developing a task to do stream processing and classify the data by an arbitrary subset of the data and don't want to model the entire structure to avoid losing/changing the original data structure. I'm sure there's better ways to do this, but that's an example I'll throw in.
- kobalsky 6y ago
  Many AAA games implement their engines in C++ but use something like Lua for game logic.
userbinator 6y ago
Progress doesn't follow a linear pattern, it's more like a jagged line slowly trending upwards. Recently (as in the past few years), it feels more like it's not trending upwards anymore, just jumping around an equilibrium point and maybe even slowly declining. Junior engineers don't know these trade offs, they end up using sophisticated hammers for their screws. They also end up making hammer factory factory factory factories. (http://web.archive.org/web/20150106004241/http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://web.archive.org/web/20150106004241/http://discuss.joe...)
- stonedartist 6y ago
  >They also end up making hammer factory factory factory factories Funny but accurate article! I did not know they saw that as a problem in 2005, which means it could be a lot more factories by now.
- acqq 6y ago
  And also, the idea of "architecture astronauts", in the text written almost 20 years ago: https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... "Why the hell are people so impressed by boring architectures that often amount to nothing more than a new format on the wire for RPC, or a new virtual machine? These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace." "Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA." Note: that kind of "selling points" was "promised to us in the past" even then. Also, not even distributed anything is necessary for architecture astronauts, one can "architect" any task: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... The oldest form of "architecture astronauts" food I personally had to fight against was Grady Booch's "Object Oriented Analysis and Design With Applications" from 1991/1994. It resulted in many enterprises wasting immense amount of time even in the nineties.
mightybyte 6y ago
"You are only an expert in a given technology when you know when not to use it" This is such a great quote. I would also love to know the origin. I'll also bite on the when not to use static typing bit. Not using static typing is a bit of a misnomer because you can use a statically typed language and just use `String` (or `Bytes`, `Object`, `Value` or whatever the equivalent is in your language). The question is more of whether to use one of these catch-all structures or to use a more structured domain-specific type. And the answer here is when you don't need all of the structure, don't want to force the whole thing to validate, etc. For example, maybe you have JSON getting read into some complex customer data structure. If you only need a single field out of the structure, and haven't already parsed it into the customer data structure for some other reason, it might be best to just reach in and grab the field you need. You can think about it kind of as the principle of least context but in a data parsing scenario.
- deleted 6y ago
  [deleted]
- h91wka 6y ago
  > I would also love to know the origin. FWIW, there's a very old Russian joke that goes like "a novice doesn't know how to do it, a pro knows how to do it, and an expert knows how to avoid doing it".
kelseyhightower 6y ago
"Unfortunately I forgot the exact quote and the author. (If anyone knows please let me know)." I said something similar in 2018[1], "You haven't mastered a tool until you understand when it should not be used." [1]: https://twitter.com/kelseyhightower/status/963428093292457984 https://twitter.com/kelseyhightower/status/96342809329245798...
- ceronman 6y ago
  Yes this is exactly the one I was referring to. Thanks!
harpratap 6y ago
You are making a lot of ageist remarks. There are plenty of Senior engineers making wrong decisions. For example the istio project moved from microservices to monolith - https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/ https://blog.christianposta.com/microservices/istio-as-an-ex... and none of those engineers are "junior engineers" by any means.

macspoofing 6y ago

>when not to use static typing I'll bite. When should static typing not be used? (Note: I agree with your general point)

yashap 6y ago
When I’m throwing together a quick script, or maybe some minor piece of automation, Python is my go-to language. For any decently large project, though, I prefer static typing.
- karatestomp 6y ago
  I'd kinda prefer it then, too. If it's short and I'm just scripting stuff up it's probably mostly calls to existing code (libraries) so almost all the static typing would do is tell me when I'm screwing up and give me hints for valid arguments with types and names, with little or no added overhead. It'd be very nice.
  - MaulingMonkey 6y ago
    Consuming types in that context is nice, defining them is what's generally a PITA / extra boilerplate / overhead. To take a concrete example that could go both ways: Say you want to parse a JSON blob for some task. On the one end, you could access it through dynamic typing, or tools like jq, that don't need a schema for the entire data format. At the other extreme, you could make typescript definitions defining a schema for the entire format. The more the same data gets (re)used, the more worthwhile taking the time to define a full schema is. But to download and add type definitions (often out of date and in need of further tweaking) for every once-off API request? Way more effort than it's worth.
    - seer 6y ago
      Most static type systems do not force you to say what’s the entire shape of the data, just what the shape of the data you need is. In fact its a good practice to do in general. So that when processing the json blob you tell what only your processing requires. What you get is that if for example you do your validation, but then by chance you touch more data that you’ve checked for, the types will tell you you are dangerous waters, and you can go update the validations. This is especially useful if you’re not the original author or if you’ve written it several months back and don’t remember the details. Static types are really cool that way, and can be treated as just a faster to write and faster to run and always up to date unit test.
ergothus 6y ago
When the communication loss (visual noise) from the added static typing info is of bigger impact than benefit type safety offers you. All of which depends on a lot of variables.
- hedora 6y ago
  My heuristic is that if anyone else will ever read the code, it should be statically typed (or be written in a language like shell where the language is essentially limited to one type). Most people disagree, but then they end up writing giant python monoliths with layers of implementation inheritance, dependency injection and functional programming paradigms. In the end, they try to port it to pretty much any other language, but at that point it’s too late.
  - empthought 6y ago
    Python has a pretty good type checker.
jbreiding 6y ago
For me it's where I'm developing a task to do stream processing and classify the data by an arbitrary subset of the data and don't want to model the entire structure to avoid losing/changing the original data structure. I'm sure there's better ways to do this, but that's an example I'll throw in.
kobalsky 6y ago
Many AAA games implement their engines in C++ but use something like Lua for game logic.

userbinator 6y ago

Progress doesn't follow a linear pattern, it's more like a jagged line slowly trending upwards. Recently (as in the past few years), it feels more like it's not trending upwards anymore, just jumping around an equilibrium point and maybe even slowly declining. Junior engineers don't know these trade offs, they end up using sophisticated hammers for their screws. They also end up making hammer factory factory factory factories. (http://web.archive.org/web/20150106004241/http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://web.archive.org/web/20150106004241/http://discuss.joe...)

stonedartist 6y ago
>They also end up making hammer factory factory factory factories Funny but accurate article! I did not know they saw that as a problem in 2005, which means it could be a lot more factories by now.
acqq 6y ago
And also, the idea of "architecture astronauts", in the text written almost 20 years ago: https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... "Why the hell are people so impressed by boring architectures that often amount to nothing more than a new format on the wire for RPC, or a new virtual machine? These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace." "Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA." Note: that kind of "selling points" was "promised to us in the past" even then. Also, not even distributed anything is necessary for architecture astronauts, one can "architect" any task: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... The oldest form of "architecture astronauts" food I personally had to fight against was Grady Booch's "Object Oriented Analysis and Design With Applications" from 1991/1994. It resulted in many enterprises wasting immense amount of time even in the nineties.

mightybyte 6y ago

"You are only an expert in a given technology when you know when not to use it" This is such a great quote. I would also love to know the origin. I'll also bite on the when not to use static typing bit. Not using static typing is a bit of a misnomer because you can use a statically typed language and just use `String` (or `Bytes`, `Object`, `Value` or whatever the equivalent is in your language). The question is more of whether to use one of these catch-all structures or to use a more structured domain-specific type. And the answer here is when you don't need all of the structure, don't want to force the whole thing to validate, etc. For example, maybe you have JSON getting read into some complex customer data structure. If you only need a single field out of the structure, and haven't already parsed it into the customer data structure for some other reason, it might be best to just reach in and grab the field you need. You can think about it kind of as the principle of least context but in a data parsing scenario.

deleted 6y ago
[deleted]
h91wka 6y ago
> I would also love to know the origin. FWIW, there's a very old Russian joke that goes like "a novice doesn't know how to do it, a pro knows how to do it, and an expert knows how to avoid doing it".

kelseyhightower 6y ago

"Unfortunately I forgot the exact quote and the author. (If anyone knows please let me know)." I said something similar in 2018[1], "You haven't mastered a tool until you understand when it should not be used." [1]: https://twitter.com/kelseyhightower/status/963428093292457984 https://twitter.com/kelseyhightower/status/96342809329245798...

ceronman 6y ago
Yes this is exactly the one I was referring to. Thanks!

harpratap 6y ago

You are making a lot of ageist remarks. There are plenty of Senior engineers making wrong decisions. For example the istio project moved from microservices to monolith - https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/ https://blog.christianposta.com/microservices/istio-as-an-ex... and none of those engineers are "junior engineers" by any means.