1. 23
  1. 29

    I am my tools.

    First, I don’t count Python or Ruby as tools. Programming languages are the raw material we turn into things, including other tools. Tools are what we use to manipulate the material. My scripts can be tools. The languages themselves, no.

    When I think of tooling, I think of cooking. I first learned to cook when I was 19. When I bought my first chef’s knife, I thought of it as a distinct entity I was working with- I called it “Clancy” as a joke. “Chopping the vegetables” was shorthand for “manipulating the knife so that the knife cuts the vegetables.” Now that I’ve been cooking for almost a decade, I no longer feel like I’m using a knife. Rather, in the state of holding a knife, I as me can cut. The knife is part of my body, so much so that hands feel different holding different knives. The shape of myself is changed by the tools I use.

    Same with programming. I need to “build abstractions”, but I think of these abstractions as TLA+ specifications and Graphviz diagrams. I need to “debug code”, but I visualize the debugging in invariants and ASMs. Sure, I am more than just my tools. But I am also more than just my bones and sinews, and I am more than just my brain. The tools I use the affect the the world in turn affect me.

    This is why I so prize learning new tools. It opens up new ways of thinking and new ways of being myself.

    1. 4

      Hillel, There is an amazing similarity in our thinking on this. I had taken some notes on exactly this topic for a future blog post: Mastering/Internalizing your tools. (This is Murat by the way.) Here are my notes to remind me what to write :-)

      shortcuts are not tools

      no pain no gain.

      if you don’t bend yourself, you did not master a tool, you are just shortcutting.

      if you master a tool, you bend yourself: there is no spoon, you bend yourself

      And, the bending of the self, is what matters, that is when you transcend and level up. It takes weeks at least.

      You can truly master a tool only when you master yourself and bend yourself with that tools thinking mode.

      1. 1

        Oh hi Murat! I’d say welcome to Lobsters, but you’ve been here longer than I have :D

        Definitely looking forward to reading whatever you write on this! And sharing my thoughts on whatever MAD questions you put on up on them.

      2. 2

        It’s funny I was looking at a friend that is cooking very well and having assisted him several time at his place, his organizarion was incredible. Few days ago he came to my place and i found him stressed out, in a rush, and over cooking stuff. Nonetheless, he still had some very good habits, like tasting often, salting things at the right moment, adding acidity when needed…

        The lesson ? He was and wasn’t his tools at the same time. Some skills are about using tools and how, some others are more generic or about knowledge ;)

        You are your tools, but not only.

      3. 18

        I chose the jobs I apply for based on the tools I use, like and know. I learn new things along the way, but I would never want to work on a .NET project on Windows for example. Those may be fine technologies, but they are not for me. The tools I know, define where I go and therefor also sort of define myself.

        1. 10

          Couldn’t agree more strongly. I used to identify as a Python programmer, and took jobs primarily writing Python.

          Then I took a job where I had no control of the tools I’d be using. In two years I wrote (approximately by lines of code): VBScript, Ruby, Java, PL/SQL, Python, Javascript, C++, and probably some other stuff for good measure.

          The Python community is still my home base, but now I choose jobs and projects by whether their outcomes are important to me, not by language, and that allows for doing much much more rewarding work.

          1. 10

            Meh, I find this line of argument unconvincing… certainly using a specific toolset, could serve as a good basis for experience. Would you hire someone who has only done web development (and maybe has some experience with algorithms) to maintain a legacy COBOL system, optimized and written exclusively for some 40 y/o mainframe? It might not be a common example, but is is a kind of ad absurdum refutation in my eyes of the generality that the author makes. A more everyday example would be if you need to write some efficient system critical component on, let’s say a unix system, it’s certainly better to someone who has read alot about unix, has already wirtten utilities, knows the system calls and the advantages and disadvantages of libraries. Writing a physical simulation? I would guess that a stable background in mathematics, computational science and small hardware optimisations (eg. ++i vs i++) would come in more in handy than knowing how to position images on a website. And to not insult web developers, they have a tremendous advantage agains all the previous examples, and if one is already making the economic argument (think about the jobs!), speed and efficiency certainly seem important.

            All in all, one might not be ones tool, but one has ones experience, expertise and is probably more fit for some tasks than others, even if it’s only because of ones interests.

            (and the editor question seems to be quite perpendicular to this issue. This is a tool, but you can prefer one over another without making this an issue about identity. You just might be more used or find it more comfortable to write dd vs C-a C-k. Seriously levating this to the level of identity shows nothing more than a personal “shallowness”)

            1. 2

              I’ve worked in multimedia CD-ROMs. Then websites. Then software for airlines, with a lot of distributed systems stuff. Then just distributed systems. And now I’m doing image processing for gene sequencing, and dredging up memories of math classes I haven’t used in 18+ years.

              I’ve written production code in 6 different programming languages along the way.

              It is easier to stick to things you know, yes, but you don’t have to if you don’t want to.

              1. 1

                If you don’t mind me asking how’d you get into writing software for airlines?

                1. 3

                  Got a job at ITA Software, which built the flight search engine powering many (a this point most?) airline websites, Orbitz, and these days Google Flights. We also built an airline reservation system, which was launched and then canceled by Google a few years after they bought ITA.

                  There’s a still a whole team at Google working on this.

                  Other companies are the big GDSes: Sabre, Amadeus, etc..

            2. 5

              I don’t believe I can disagree more. Tools matter, because some tools are better than others on some axis or axes. ‘Tools don’t really matter’ is the only argument one can make when one can’t argue ‘my tools are better.’ I don’t think any particular tool is better on all axes, but certainly some aren’t the best on any axis (e.g. pico).

              And I don’t think it’s inappropriate for someone who recognises a tool’s actual excellence in a world which incorrectly fails to do so to make that recognition part of his identity. It’s part of how an oppressed minority perpetuates its existence.

              1. 7

                This is a good point, but it’s also an argument against strongly identifying with your tools. If tomorrow you encounter a new tool that does something better than your current tool, it should be as easy as possible for you to abandon your current tools and take up the new ones, and that’s harder to do if being a user of a particular tool is part of your self-identity.

                1. 3

                  “Oppression” seems like an overly strong word here, maybe…

                  1. 1

                    If you’ve ever been an emacs-user on a team of vim-users, you’d know what I mean. Or a Linux-user on a team of Mac-users …

                    No doubt the other way ’round is the same, too …