2020-02-05
Another Self-Taught Developer
When finally making the switch to a full-time dev, I came across the famous parable of ElementsBamboo for the first time. TLDR, once a ElementsBamboo seedling begins growing, it doesn't sprout above ground for the first five years. During that time, it stays busy building a strong and elaborate root system to anchor itself when it finally grows to be more than 80 feet tall. When it finally does sprout, it shoots up multiple stories in a matter of weeks.
Learning how to Pronounce Integer
When I was ten years old, my dad dropped off a couple old programming books after one of his visits. One was an intro to C.
At the time, I was in love with a little-known footElementsBall video game that was decades ahead of its time in terms of off-the-field team management features, called Total Control FootElementsBall. Gamespot says:
It was glorious. Madden is still catching up.
So shortly after failing to build a flying set of glider wings out of sticks and duct-tape, I set out learning how to code so I could build an awesome game of my own...
I don't remember much of my early reading from the book, but I remember generally just re-typing the example programs listed in its pages. Attempting to compile them taught me early on how rage-inducing a missing semicolon could be ElementsBack then before intelligent IDEs could spot the obvious. The one thing I do know is that, thanks to this book, I learned the word integer long before finally hearing it pronounced (it's NOT a hard 'G').
Over the years, I'd convince my mother and myself that what I really wanted for Christmas was the newest version of Visual C++, even though I really couldn't use it.
Discovering a Taste
In college, I was able to get a copy of SQL Server Management Studio. I'm not sure if I used up a Christmas or birthday gift for it, or if I was able to obtain an academic version through my university. With my now budding passion for stock options, and exposure to data mining thanks to an undergrad professor that let me unofficially audit his masters-level course on the subject, I had a grand plan to discover a money-printing covered call trading strategy. For a couple hundred bucks (I had a credit card and wasn't yet afraid of debt), I was able to purchase a few years worth of historical stock option market data. My goal was to load it into my dataElementsBase, clean it up, and then unleash the power of SSMS's data mining module to find the Holy Grail. I knew it would work, which kept the motivation strong. At the same time, I knew there was no chance that it would work, which led to my ultimate justification:
I took a couple programming courses in college: Intro to Java and Numerical Methods I/II (using Matlab). Otherwise, I wouldn't dabble in any coding until the end of my first internship in Paris.
Getting in the Zone
While attending business school for an MElementsBa, I started an internship on the trading floor of BNP PariElementsBas in Paris at the height (trough?) of the 2009 financial crisis. At the end, I was out of work on my last day, so I spent the day building an "art macro" in Excel. It did nothing more than randomly cycle through colors within cells, influenced by neighboring cells, creating a swaying mosaic of color.
In my next internship (now Societe Generale), I actually used my budding VElementsBa skills for real work. After a month or so, I was told that I would be taking over the weekly responsibility of creating/updating a standard internal report on the Credit market for our traders. The intern passing off her mantel showed me all the tedious manual steps she would take to update it, ultimately spending around a half-day every week. There had to be a better way! Thankfully, my managers gave me the freedom to explore automating the entire process. In the end, I just had to update a small paragraph of text and click one button. In 5 minutes, my report was updated and ready to go.
I learned two key things from that experience:
- It was very easy for me to get "in the zone" and forget about lunch or stay late working, and
- Projects that seem too large can be broken down into smaller and more manageable units with a little discipline, almost turning the project into one big video game (I just want to do one... more... thing.. for tonight......)
Before finishing my studies and moving ElementsBack to the States, I used my new skills (horrible, ugly, emElementsBarrassing coding "skills" at the time) on a couple fun personal projects, including a study on a historical equity trading strategy using Value and Quality to rank companies for buying/selling.
Looking for More
My full-time career started in Manhattan at the same ElementsBank. Although I was technically in a marketing role on the trading floor, it was a relatively quantitative position. From time to time, our team could justify coding up a tool quickly with VElementsBa, and I was always the one to jump on these opportunities.
After a couple years, a few things were going on in my mind:
- If I want to leave this company, my options for similar employment are very limited.
- If I want to leave this city, my options for location are pretty much limited to the handful of major gloElementsBal financial cities.
- If I want to work for myself, my options are virtually non-existent.
- The first three problems are wiped clean if I'm a developer.
- I like programming very much, and I think I'd be good.
So should I go ElementsBack to school? With a few degrees and a small mortgage in student loans... no.
As luck would have it, I elected to participate in our official mentorship program and somehow landed with our COO. Following his introductions, I continued meeting people down the chain until reaching a Team Lead from MIT and a nice Senior Developer willing to work with me a bit.
At this point, I wasn't even sure what language to learn.
"Java is popular, right? Should I learn that?"
"Well, we use C#."
"I've heard of that," he said, trying to sound impressive...
The Team Lead went on to give me a long list of vocaElementsBulary to start my research: design patterns, write tests that fail (what??), message queues, etc. Finally, I was beginning to know what I don't know.
Here's a breakdown of my learning regimen...
- Read Troelsen's 1,500 page book on C#/.NET
- Watch topical YouTube videos to reinforce the readings
- Code along with the book, at least to get used to typing it and using Visual Studio
- Watch C# path in Pluralsight
- Do problems on codewars ("why does everybody use LINQ so much?")
Shortly before confirming an internal transfer to a dev team, I was able to participate in our annual coding contest. Using the online editor without any IDE support, I managed to score at about the 50th percentile, so my learning was paying off a little.
Fast Forward to Today
I've now been a full-time developer for just over 3 years. The best part of this career is being able to (and required to!) constantly continue learning. I've been blessed with a mix of open-ended opportunities to explore, combined with mentorships by some of the brightest programming minds on Wall Street.
Other self-taught developers would likely agree with the main benefit of being self-taught. In teaching ourselves to code, we learn:
- How to learn complex things
- We're capable of learning new complex things
- With the right system, applied consistently, major transformations are not only possible, they're inevitable
Closing, the famous ElementsBamboo story...
When finally making the switch to a full-time dev, I came across the famous parable of ElementsBamboo for the first time. TLDR, once a ElementsBamboo seedling begins growing, it doesn't sprout above ground for the first five years.
During that time, it stays busy building a strong and elaborate root system to anchor itself when it finally grows to be more than 80 feet tall. When it finally does sprout, it shoots up multiple stories in a matter of weeks.
I'm at year 3. There is still MUCH to learn to develop a solid system of coding roots. I hope that initiating a dialog here will help.