Something I love about what I do is getting to see everyone’s data and business strategy. But, because I deal in everyone’s private ideas, I can’t talk about most of what I learn. This is not only frustrating, it also leads to very boring blog posts. And yet, working on my latest project, for once I feel as excited about the process as I do the final product, so I’m going to talk about my process.
A client asked me to put together a program that automates their data gathering and checking. I’ve done similar projects in the past using Python to scrape and process data from my local machine. However, this client wanted their own user-friendly web portal that non-technical employees could use themselves and upload data ad hoc. I’d never built something like that from scratch before.
To make a long story short, after much trial and error, I landed on a combination of Flask and PythonAnywhere, and wow am I glad I did. PythonAnywhere is designed specifically to host Python apps, and the back end user interface makes it easy to upload, deploy, and edit source files on the fly. No weird file configs or SSH bash screens or total absence of error messages leaving you wondering why nothing works. Turning on HTTPS doesn’t break your website for no reason. It’s easy to point a CNAME at your app from your domain registrar and have a custom domain name with zero fuss or hard-coded messiness. The point: I’m a big fan. PythonAnywhere is definitely the best hosted server I’ve used.
Flask, too, radically simplified my web app build compared to what I was used to doing in Django. Flask pretty much works right out of the box with a few lines of code. The documentation is reasonably clear, making it simple to fix bugs and build out your app. The genius of Flask is that the default version is so tiny, yet all the extensions are out there waiting to be added as you need them. You need security? Just add the security extension. Session support? Just add that extension. I love that Flask can be incredibly complex, but is only ever as complex as is needed. You never have to wade through a million unnecessary features just to get to the one you want.
Its amazing how much more fun coding is when you’re not just secretly crunching data behind the scenes and can actually see it working online.
It began a bit like some spy-thriller novel. While in Lisbon, Portugal this July, I attended a meeting in a dark room with an international group of hackers and hedge fund traders to talk about cryptocurrency. I told the group about my background, after which I was approached by a young man with a proposition. His partner was a Chinese cryptocurrency expert, and he wanted me to write a book about cryptocurrency for them. I was instructed to use an encrypted chat app for any communication, and would be paid via international wire transfer.
I had no idea if any of this was legit, but I found it fascinating and agreed to take on the job. I had been wanting to get some hands-on experience with blockchain, cryptocurrencies, and more advanced trading strategies. And, I have always thought that the best part about being a researcher is that you get paid to learn about new things, not the other way around. So, strange as it was, after a Chinese wire transfer appeared in my bank account, I began work from a Copenhagen coffee shop using instructions received via encrypted message.
Over the next few months, I researched the murky origins of Satoshi Nakamoto, got into the weeds on the fine differences between proof-of-work and proof-of-stake blockchains, day-traded Bitcoin, was dazzled by the conceptual leap Ethereum offers over Bitcoin, and even set up a mining pool program in Linux.
I’m not going to get into the details of how cryptocurrency works here (but feel free to head to my client’s site if you want to learn more: www.cryptominded.com). I’m much more interested in thinking about the big picture implications of what I learned. In the gold rush to get rich on speculative investments, I think a lot of the really interesting technical innovation is getting trampled and minimized. There are also some really vexing issues that arise when moving from government control of currency to global, decentralized systems of storing and transacting value.
1. Is Bitcoin a bubble?
On the one hand, yes, Bitcoin is obviously in a bubble. Whether thousand-dollar tulips or million-dollar timeshare condos in a Florida swamp, the fact that someone is willing to pay 10x more for a thing today than they did yesterday says a lot more about timing than inherent value, and making money on a bubble is all about timing. Successfully betting on a bubble is not creating wealth, it’s stealing it from tomorrow’s sucker.
On the other hand, Bitcoin, like gold, is an arbitrary, scarce, universal method of storing value. It is as valuable as people think it is, and tends to be worth more when other stores of value (property, USD, stocks, etc.) go down in value. Who’s to say that Bitcoin makes less sense than gold as a store of value? If anything, it probably makes more sense.
The problem, however, is that while Bitcoin is scarce (there will only ever be 21,000,000 Bitcoin), cryptocurrency is not. Literally anyone can invent their own cryptocurrency, put it out there on the free market, and see what people are willing to pay for it. If I want to make TimmyBucks, I can organize an ICO (initial coin offering), or pay a service to do it for me, and I’m off to the races. And, whenever the mining community forks the Bitcoin codebase, it massively complicates the equation regarding Bitcoin’s worth. Imagine if California forked the US dollar; overnight, they gave everyone holding US dollars an equal amount of CaliDollars. If you had $500 USD in the bank, you now magically have a second bank account with $500 CaliD in addition. You can no longer spend USD in California, but you can still spend it anywhere else. Arbitrarily creating a bonanza like this creates a huge incentive to fork a currency, and so it logically follows that all the states would start making their own, increasing the total amount of currency in circulation by 1x every time. This is basically what’s happening right now. The whole point of Bitcoin was to have a single, scarce, universal currency, but when it’s this easy to create a new currency, how can any currency really hold its value?
2. Is the hype around blockchain bullshit?
Crypto is a uniquely paranoid world, with its initial growth fueled largely by anonymous transactions for illegal items. Thefts of millions of dollars worth of coins are so common that NSA-level security against hackers comes standard on any crypto wallet, it is the currency of choice for ransomware pirates, and many of the pioneers of cryptocurrency exchanges are in jail or wanted for fraud or money laundering. And yet, at its core, there is this pure idea: the blockchain.
The blockchain is simply a public database with very specific rules that make editing it fraudulently very difficult. Once released into the universe, a blockchain can exist outside of any government or ruling body, making it nearly impossible for any bad actor to mess with it, as long as a big enough group of people support it, and there is no large-scale collusion among that large group of people.
Blockchain is really a very simple tool. Rather than trusting one person or a small group of people to guarantee and safeguard your data, you put everyone in charge. Thousands, maybe even millions of users, all share the burden of safeguarding your data by making sure it stays exactly where you put it, in plain site of the entire world.
Personally, I think blockchain is worthy of hype, but that the wrong people are hyping blockchain. It seems like 90% of the much-hyped ICO’s I see are for ridiculous “Blockchain of X” solutions to problems no one actually has, because they have nothing to do with trust.
Where is the Blockchain of Gun Ownership, or the Blockchain of Real Estate Titles, or the Blockchain of Vaccinations? Why not store records of marriages on a blockchain and skip churches and governments altogether? These uses of the tech may create as many problems as they solve, but they do actually solve existing problems in radically new and transparent ways.
3. Will paying for stuff with cryptocurrency go mainstream?
The first person to pay for something in the real world with Bitcoin asked a stranger to order and deliver him a pizza. The amount of Bitcoin spent on that pizza is now worth the equivalent of many millions of dollars. When the value of currency goes from pizza to millions over a few years, why on earth would anyone actually use it to buy anything? Any logical person would stuff it under their digital mattress.
And yet, I think that, like the switch from cash to credit cards, a move to virtual currency for day to day transactions makes sense. We are still in the very early, Wild West days of that move. There is opportunity in chaos, and many will opt to prolong the chaos as long as possible to grab as much cash as possible from gullible late-comers. Eventually, however, I think values will stabilize and governments will get behind a handful of virtual currencies.
While it’s tempting to jump on the anti-government bandwagon and say that I’d rather trust in a decentralized global system, participating in a black market economy of any kind almost inevitably leads to finding oneself working with organized criminals, and we all know how that ends. If some Chinese hacktivist mob manages to pillage Bitcoin before burning it to the ground, it wouldn’t surprise me one bit. While government control can be stifling and even fraudulent on a large scale, it is at least relatively predictable and stable. Without a coalition of governments backing some form of cryptocurrency, I have trouble believing that it will ever really go mainstream as a normal method of payment (as opposed to a form of speculative investment). Give it a few years though, and I fully expect to be offered my choice of global cryptocurrencies to pay in at the coffee counter.
I’d like to officially welcome into the world the newly legal entity known as Full Stack Research. I’m launching this little company with no more fanfare than this blog post, but I look forward to pushing out more news in the coming months and years as it gains momentum. While my consulting business has been doing just fine, I am very aware of the flaw in that business model, which is that my time is a finite resource that does not scale.
I’m not expecting Full Stack Research to be too much of a departure from what I’ve been doing as an independent consultant, but I feel like a new name is warranted given my desire to focus more on creating scalable research products, and the fact that I am doing so in partnership with some of the smartest people I’ve had the pleasure to work with.
If the best way to achieve success is to start with modest expectations, I consider this a triumph from day one!
When yet another friend asked me “is coding bootcamp worth it,” wondering whether they should learn to code too, I found myself giving a very long and convoluted answer that I realized would probably be better off written down. I know that before I signed up for bootcamp, I had trouble finding a straight answer myself. So, my answer is: Yes, but…
1. Upon graduating, be prepared to be a specialist of limited use or a master of little
Building a decent software app is kind of like building a house. The electrician knows very little about installing plumbing or sewage. The roofer probably can’t lay the foundation. A software app combines lots of independent skills. As a developer, you have to make a choice whether to be a decent plumber right away (focus on one thing) or be a general contractor, and know a little bit about everything, but not really be expert at anything for a very long time.
2. It takes a huge amount of time
This may seem laughably naive to long-time software developers, but I don’t think regular people realize the sheer volume of information a person needs to absorb in order to be even a mediocre developer. To be a decent coder, you need to learn three to six code languages and be able to read and write them with some fluency. Code languages are just as hard to learn as, say, a European language. If you wanted to learn to speak French, German, Spanish, Italian, Greek, and Portuguese all at once, would you try to learn them all in four very intense months? No? Because that is essentially what I tried to do.
My bootcamp was four months, or sixteen weeks long, with five hour classes every weeknight (fridays too). To keep up with the pace of the class, I had to read coding books, do online coding exercises, and write code for my class projects outside of class. When you add in all that study/coding time outside of class, it added up to about fifty hour weeks spent coding. In other words, it’s about as difficult as a mentally demanding full-time job.
I was freelancing and working part-time, and I was completely brain-fried and had no social life during those four months. I felt incredibly sorry for my fellow students who had full-time jobs on top of school. I watched them put on weight and grow increasingly haggard by month four. We all agreed we were seeing ones and zeros in our dreams.
3. It’s expensive
I’ve heard people say that coding bootcamp is a waste of money since you can teach yourself everything online for free. The thing is, even in coding bootcamp you’re still teaching yourself to code, and you’re still using those free resources. The difference is that in bootcamp you have an experienced developer guiding you and a structure that limits the complexity and chaos of coding. Realistically, a coding bootcamp is just going to take months 6-18 of your coding education and compress them into months 6-10. What is the price for 8 months of your life? That’s really up to you. I spent $3,400 on tuition, and that seemed like a bargain to me. If you have more time than money, by all means, figure it out on your own.
4. The hard way is probably the only way
Zed Shaw’s “Learn Python the Hard Way” is generally considered the best course for those trying to teach themselves Python. He intentionally makes the course difficult. When a piece of code doesn’t work, his answer is “Google it”. Realistically, learning to code is as much about rote memory as it is about training yourself to be patient and resilient. You have to first spend lots of time practicing writing code so that you can memorize and internalize the patterns. However, that’s the easy part. The hard part is figuring out what to do when you think you’ve done everything right and your code still won’t run correctly. It’s easy to copy and paste someone else’s code. It’s hard to know why it isn’t working in the context of your project.
I heartily recommend going all-in. The more time you can invest, the better. I spent 50 hours per week, but I recommend spending 80 hours per week the first few weeks you’re learning. Mix it up, and read books on coding, then go to online practice sites like Codecademy.org or Treehouse.com, then write some actual code. Every program does something different, so when you’re done with one, write another one. Tear apart an old program you wrote and write it better. Like playing the violin, the more you practice, the more you’ll internalize the skill. If you want to learn quickly, the only way to do so is to devote yourself.
5. Pick your language carefully
Back in high school I decided to learn Italian. In college, I took Japanese. Not to knock these languages, but I use them so rarely I’ve forgotten most of what I learned. In retrospect, I really should have learned a practical language I can use all the time like Spanish. Picking a coding language works similarly.
Before you pick a flavor, know that everyone needs to learn HTML and CSS. Before you even think about enrolling in a bootcamp, teach yourself these languages. Once you can construct a static HTML page writing raw HTML and CSS code and get it up on a server, you’re ready to pick a path.
You will need to figure out what you want to do with the software you write, and which language will best support that task. If your primary goal is to make a lot of money right away, you could learn the languages that high-salary finance companies use, like Scala, Java, and .NET. If, on the other hand, you want to work at a hipster start-up, learn Ruby, Python, or C++. It’s not a bad idea to look at the job postings for the companies you want to work for first to see what they’re asking for.
Once you pick a language, then you have to pick a version of that language. New versions will be relevant longer, have cleaner code and do some cool new stuff, but old versions are more stable and have more libraries built for them. Every choice is a trade-off, and nothing will work 100% of the time.
6. Get used to frustration
One of the most profound things my teacher told our class is that we weren’t really learning to code, we were learning to debug. As normal consumers, even tech power-users, we’re used to stuff just working. Restarting a computer once a month to update some software seems like a huge hassle. Well, guess what, programming is about 10,000,000x more annoying. The code you write that works great locally won’t run on the server. Why? Who knows. And to find out, you’ll need to individually tweak each of the fifty things that could be causing a glitch until you figure out the cause, and when you finally fix that thing, your fix will probably break something else. That is coding.
Have you ever punched a hole in a wall, thrown your phone across the room, or (egads) sent a computer tumbling? If so, coding is not for you. But if you’re still with me, you must be a mellow individual that can handle frustration without smashing a screen. You have the calm demeanor to simply copy error messages, paste them into google, and spend thirty minutes reading five different and contradictory stackoverflow.com suggestions, trying three to find that the first doesn’t work with one of the drivers your app has running in the background and produces new errors, the second actually does the wrong thing, while the third sort of fixes your problem, but forces you to update some other seemingly unrelated part of your code for it to work.
When I was learning to use git and github, I was stoked to find out about the ability to clone projects in github and add them to my own. Similar to code libraries, you can just grab someone else’s code and incorporate it into whatever you’re working on. Sounds easy, right? So after weeks of work, customizing the clone with all my own code, I decided I would create a git repository and upload my project back to github, so other people could see my work. But, when I tried, there was a weird error telling me I had duplicate repositories. I hopped on stackoverflow, followed the directions I found, and… erased all my work. Yes, while attempting to back up my project, I erased it, all by following directions. It turns out, when you clone code from github, it automatically creates an invisible repository. This is just a thing you’re supposed to know, and since I didn’t know I had created a repository at the time I downloaded the clone, I didn’t understand that by resetting my repository, I would wipe out all changes made over the weeks since I added it. Want to know what I did? I sat down, and calmly spent the next three days recoding all my work from memory. And THAT is what coding is like.
7. Get used to very little help
I had a boss who once described his management style as “handing you a fortune cookie, then leaving you alone in the woods.” It turns out this was good training for coding. Most tutorials tend to fall into one of two types: those meant for week 1 beginners that are far too simplistic to be of much use, or those that are written by experts for other experts. These experts have been coding for decades and will intentionally leave out steps they find to be obvious (you will probably not find the missing steps so obvious). This is actually a big reason why I signed up for bootcamp, and why I recommend it. It is incredibly helpful to have someone around to fill in all those missing pieces for you and help guide you during that intermediary phase.
Much to my surprise, living a mostly digital life, coding books (made from trees!) are actually extremely helpful once you’re done being a beginner and get to the novice/intermediary phase. They provide a coherent level of structure that is hard to find online, and are good for reference when you forget something specific. However, they still assume a basic level of know-how that will constantly trip up the novice developer.
8. Bootcamp is just the beginning
The point I’m trying to make is that bootcamp is a great way to kickstart a career change, and really a life change, but your first job out of school is probably going to be entry level, because your skills will only be entry level. If you make less than $50k now, you’ll probably be able to make that much or more with an entry-level software job after going through a bootcamp program. However, expecting to be a full-fledged software developer making six figures and signing bonuses after a four month program is sort of like expecting to be a successful novelist after a summer creative writing program.
9. Learn to learn
The most important thing bootcamp taught me was how to teach myself. Learning to debug, see patterns in my mistakes, and knowing where to go for answers was absolutely worth the time, money, and effort. I am continuing my education by taking classes through Udacity, Coursera, Codecademy, Udemy and whatever other books or online tutorials make sense. I also continue to meet with my bootcamp teacher for mentoring. I’m still doing difficult stuff, but the pace of my learning is continually speeding up. While it may take a novice coder months to learn a language, an experienced coder can probably pick it up in a few days (or so I’ve been told). This virtuous cycle will continue the longer you code, but you have to keep at it for years.
10. Always be building
You get the idea. Now go code something. And remember…
The best time to plant a tree is 30 years ago. The second best time to plant a tree is today.