What Changed, Grasshopper?

Once, a long time ago, I was a green lil Grasshopper. Now in (typical) ass-backwards, do-the-opposite-of-everybody, anti-trajectory-ness, I am again a grasshopper. Having arrived back at the beginning, I have a story to tell about the inbetween.

Why did I decide to wade back into coding, a second time around? Here’s a bunch of why’s:

1. The internet sort of “dotcom-boomed” again. (Or, “In which she immediately ages herself”): There is a wealth of information online now that there just wasn’t when I first started out. There’s almost no excuse now, for not being able to at least start the journey with a new piece of technology. There’s API docs, how to’s, readmes, code snippets etc. everywhere. This is a stark contrast to being told to RTFM (read the fucking manual). For those who don’t know, the “manual” (man in *nix systems) was a terminal utility with terse prose in fixed width font, that you paged through on a black screen. A joyless UX, if ever there was one.

2. The less challenging tasks ballooned in volume, relative to the challenging ones.

   • I suspect, without evidence/proof, that we can’t compare the logical depth of problems in (say) javascript-stack world, with that of problems in the Operating Systems, compiler design, database engineering, low-level internetworking, CPU architecture and design domains. Or if there’s no difference in complexity, the complexity simply presents itself differently.
   • Stacks are getting fatter all the time (it’s insane what you have to wrangle with these days just to spout a bit of css-tinged html into a browser)… but generally, systems programming and its ilk has been the layer underneath everything, and it was the “everything” that grew and grew and created jobs for people like me to come along later and fill. Being fullstack is challenging, but I find it manageable compared to staring at multi-file development in unix, with vim as my IDE, trying to make make and gcc do as I bid them, and figuring out why shared objects aren’t linking dynamically. I am writing this with more than a whiff of PTSD though, so perhaps don’t mind me. Don’t mind me at all… 😆

3. I changed. A lot of my missteps with coding can be laid directly at my own feet: I used to have a lot of “fixed mindset” thinking around code which has given way to a more “growth mindset” approach (I still falter sometimes, under my own steady lash). This happened quite organically without any determined intervention on my part: I just slowly came to the realisation that for the most part, people know things because they do things and they go out of their way to learn about things… they don’t have some sort of magic gene switched on at a cellular level that noone else has. This has made the biggest difference, I think. As such, I’m more willing to experiment with things / take more risks in general. That said:

4. The industry changed… and yet somehow didn’t.

   • Tech really, really, REALLY believed (and still believes) it was and is a meritocracy. And meritocracies were (back then) deemed flawless, and as such no introspection whatsoever took place within the industry as to why it was so demographically skewed. The answer to skew was, implicitly, a sort of “everyone else must just not be clever enough” rejoinder.
   • It’s still a meritocracy-believing industry, but at least it’s willing, these days, to have discussions now about what constitutes the “merit” at the core of its ethos. That said, that the industry believes in meritocracy, whether or not it actually is meritocratic, and whether or not such things are flawless… is the gap that, ironically, I and countless others continue to squirrel through.

5. I got comfortable with failure. The other thing that has made a big difference is that now, I will be the first person to put up my hand and admit complete idiocy. “I don’t know”, “I’ve never used that before” and “I don’t know how to do that” are so freeing to be able to utter. Because it doesn’t matter what you don’t know. It only matters what you’re capable of learning / coming to know.

6. I hobbified coding.

   • I want to preface this one with the fact that some people are inescapably strapped for time and mental bandwidth due to life concerns. As such, hobby-coding and side-projects aren’t going to be equally feasible for everybody, at all times.
   • That said, thinking is overrated in all aspects of life and coding is no different: Doing software development trumps “thinking about it” on any given Sunday. (Planning your approach with scribbles on paper / whiteboarding counts as doing, btw). Reserve “thinking” for comparative analyses of architectures, scaling and security requirments, and ponderings about alignment with business needs within a business context. Other than that if you’re still learning, you should be doing. Crank up a side project. Even if you barely find time to work on it, have it there and waiting upon your return to peace of mind, when you can hack at it a little. I can’t stress this enough, and it’s advice I myself should be taking more of.

7. I followed better devs like a puppy

   • Having someone ahead of you in your learning journey is worth its weight in gold… if you pay attention to them. You can learn so, so much at the side of someone more senior than you - especially if they also give you the time of day. A fancy word for this is “mentor”, but don’t get distracted by this particular packaging of the concept. The point is, it’s infinitely useful to have someone ahead of you (sometimes even just a few paces ahead of you)…
   • In the past, I thought the best devs were simply “go-to” people who could answer my questions. It did not occur to me to actively understudy them (because remember, I had a fixed mindset: they were just clever people, who just magically had all the answers). Don’t be like that. Take it upon yourself to apprentice your way further into this, your chosen craft, at every opportunity.

8. I realised my IDE is supposed to be a navigator, not an editor I am ashamed at how long it took me to grokk this.

   • Starting out, I (mis)understood code editors to be… editors. Things for typing out code. My IDE was an output device for my thoughts. It followed then, that I had to hold and comprehend the entirety of the program at hand, in my head, and innately know where each of its features and bits of logic could be found. This is in spite of the fact that even terminal-oriented editors like emacs and vim had a wealth of code navigation features. I only focused on the shortcuts for, literally, editing text.
   • This mindset problem went away as IDEs improved, and I began to understand that IDEs are tools for navigating the codebase as much as modifying it: quick lookups, definitions, and the all-powerful search features. What this helped me to do was let go of worrying about holding the entire beast in my head. I got comfortable with looking at short sections of code, out of context, with the comfort that were I to need context, it’d be just a search, drilldown or split-pane away. This frees up mental bandwidth.

I left coding behind, once. Though, I never left the IT industry… I was always milling around with a different hat on… So I’m a bizarro hybrid newbie-veteran… whatever that is.