For the first time yesterday, my long time friend Kegan joined my wife and I on a quick grocery run. Since we’ve been married, Charlane and I have been buying groceries once every 2-3 weeks, so this trip to Fairprice felt familiar, almost habitual. That’s why when Kegan remarked at something I said to Charlane about the bananas she chose off the rack, it was a moment of revelation.
“Those look too yellow,” I said. “You should grab a greener bunch. They’ll last longer.”
Ever heard someone tell you that your code is not “DRY”? What’s the deal with that? Are they saying that your code can hold a lot of water…?
Sorry for the bad joke. DRY is an acronym, and it stands for Do not Repeat Yourself. As far as I can tell so far in my short career as a software engineer, this is one of the most revered principles in writing software.
In this post, we’ll explore why it’s important to keep your code DRY and in general, how you can go about doing it.
I’m inspired by how driven some people can be. It’s not everyday that you get genuinely impressed by someone’s energy, particularly not through social media. But I did today and after the inspiration surged through my veins, I find myself just sitting here and wondering two things. Why the hell am I sitting here watching people do stuff? What will I do if I had that kind of energy?
Let’s get one big thing out of the way first. “That kind of energy” is not something some lucky or special people are born with. No, I don’t buy that. It’s obviously nurtured. I know this because I’ve felt incredibly motivated before, and chances are, you have too. It depends on what you’re doing. I think we just need to do something we’re decently good at and find meaningful. That’s the trick to getting “that kind of energy”.
Well, at least part of the trick. There’s an important part that is less examined, I think, and that’s our natural tendencies.
I naturally tend towards being in quiet places. Without supervision, I also tend to be lazy. If I had the lovely evening after work to myself, I tend to not create but consume. And even though I recognise that this is inhibiting my growth as a professional and as a person as a whole, I just tend to be lazy, you know?
Now here’s a non-revelation: a tendency to (not) do something is a phenomenon, a manifestation of some underlying idea. I think the idea that underlines my tendency to consume instead of create (ie. being lazy) is that there’s no need to work so hard all the time, every time.
After a long day’s work where I’m not lazy (it’s a professional environment), why get home and do more stuff? Productivity is a business idea. Sounds fair enough, right?
What I haven’t realised before is that the way I think about after-work work is wrong. Calling it after-work work is already a fallacy. While not working hard all the time is something I still agree with as a general principle in life, the things we do during time we have after work and on weekends (minus that which is spent with family) are not work. They should not be called work.
The things we do in our free time are expressions.
Expressions of our expertise gained from working hard at our day jobs.
Expressions of our creativity, pent up and brewing from every walk around the block, every moment of politicking, every pocket of thinking unmolested by distractions.
Expressions of our identity, as a “writer” or “programmer” or “some other label”.
Expressions of us. Me. You.
Witnessing this stranger’s expressions on social media today helped me come to this epiphany. On the surface, it looks like this person has unbelievable energy. Something unique, something unattainable. Born with.
But as I dug deeper, I felt more uncomfortable. What’s the secret? Why is she doing all that and I’m here doing all… this? Sitting here YouTube video-hopping. All this while knowing in my heart that I really want to read a book, write something or strum my ukulele.
I think that was when it hit me. As much as I do, this person I stumbled upon from watching one too many videos on YouTube probably doesn’t see herself as working hard. That’s me seeing the world through my lens. Through her lens, she’s just making good use of her time expressing herself!
To put this new idea to the test, I sat here, in my swivel chair at home staring at my monitor with my dog Brownie lying on the floor next to me. I told myself this isn’t work. I am not working. Whatever I do now is extra, it’s unaccounted for. Whatever I choose to do now is just an expression. So… what will I do?
It took five minutes for my mind to accept that this idea might have a kernel of truth, but when I did, I suddenly felt the urge to write. What I wrote is what I’m writing now.
(This is by no means justification for always writing only when you’re inspired, nor is it an excuse to write unfiltered, stream of consciousness essays all the time. Too much of either lands any writer in a world with few and mostly unenjoyable essays.)
So… what’s the TLDR?
Stuff we do in our free time should never be seen as “work”
The notion of “working hard all the time” confuses us into thinking that if we do anything productive in our free time, we must be working too hard
What we do in our free time are expressions
When you express yourself, you appear to have high energy
When you appear to have high energy, you actually have high energy
When you have high energy, you’re happier and express yourself more
Ultimately, for maximum happiness, focus on expressing, not consuming or even “creating”. Now I get why the prolific reader-writer Maria Popova says “there’s nothing more toxic than calling your writing content”. Just express, don’t create and measure it!
Between 2016 and 2017, I went from knowing nothing about code to becoming a software engineer at Metisa, a startup that is building an end-to-end data science solution for e-commerce businesses. It went smoother than I could ask for, but that is not to say that I didn’t second guess my decisions at every turn. In this article, I’d like to share what I’ve learned from attending programming bootcamps – I attended the same one once as a student and once as a teaching assistant. My hope is that this would help you make an informed decision about entering tech via programming bootcamps, if you are interested.
Less than a year ago, I was a non-technical founder of a technology startup. That did not go well, and I was losing confidence in myself everyday for not understanding, at a fundamental level, what it takes to build a great tech product.
When the time was right to hire interns from the School of Computing at my alma mater (NUS!), I hit an impasse and stopped working on the product altogether. That was when I started to learn programming, first on my own using free online resources like FreeCodeCamp before eventually enrolling in General Assembly’s Web Development Immersive in Singapore.
I don’t want to dive into the specifics of the General Assembly course (I’ve written a review for that) but instead, I’d like to reflect on programming bootcamps more generally. What are they and why are there so many of them now? Do they deliver results? Should I join one to make an entry into tech? I’ll indirectly take a stab at these questions with the bullets below.
1. Programming bootcamps are sprouting in response to demand
I’ve noticed programming bootcamp providers like General Assembly and Alphacamp and many others setting up shop recently. It probably began much earlier in tech hotspots like San Francisco, but in Singapore I’d place the start of this trend to be around 3 years ago. Their boom is likely attributable to market economics: there are more companies currently trying to hire software engineers than there are software engineers to hire.
Consensus among the people I know who have gone through programming bootcamps as well as those who help teach them is that it is an exciting time to be a software engineer. Aside from the code literacy movement, it is exciting because many companies are hiring. If you are good enough (we’ll get into that later), you are likely to have some bargaining power.
The operative word here being “good”, of course. It’s difficult to justify having to pay upwards of SG$3,000 to employ a bootcamp graduate who needs handholding and constant guidance. This difficulty is exacerbated by the fact that the majority of tech companies are really tech startups. In other words, teams that consist of 3 to 10 people. Let’s just say that these small organisations will never be in the mood to hire people who can’t contribute almost immediately to their teams.
So while demand for software engineers is strong, you will still need to prove that you are capable of contributing to the team quickly. Which is perfectly possible if you are focused…
2. Much to cover in little time
What is it like trying to become a professional software engineer just by going through a 12-week course? One word. Tough.
If you have a friend who is joining a course half-heartedly, or you are thinking of doing that, please be careful. While it is not implausible that you will end up fine, it is highly unlikely that you will. There is a lot of ground to cover in a short amount of time.
Here’s a non-exhaustive sampling of things you will need to get used to or become good at in 12 weeks:
Getting comfortable reading code (eg. if x = 3 and y = 4, then x = y is not an error but a reassignment of the value of x to the value of y (x is now 4))
Reading code written by others
Talking through your code (“This chunk should be abstracted to another function, which takes in 2 parameters…”)
Debugging code that is not working
Designing database structures
Understanding the performance of your code (nested for loops is almost never okay)
Finding answers to multiple super specific questions simultaneously
Memorising 30 keyboard shortcuts that make coding quantifiably faster
Understanding the workflow that software engineers use to collaborate (“Git”)
Learning new technologies, concepts, frameworks after you’ve just learned a dozen (Webpack, Babel, SCSS, LESS, ReactJS, Angular 2, VueJS, TypeScript…)
To become proficient in making web applications that people actually use, you will need to be conversant with all the above to some degree. If it seems like a lot, that’s because it is!
That said, when I was a student at the Web Development Immersive at General Assembly Singapore, I constantly reminded myself that the level of intensity I was experiencing was a feature, not a bug. I didn’t want it any other way, because it’s supposed to be intense. If it isn’t, I would feel like I was getting a bad deal. And that would have probably been true.
So prepare for an intense few months. Go all in, or don’t go at all! This segues nicely into the next point…
3. Programming bootcamps leverage the cohesive power of self-selection
They say that true friendships are forged through hardship.
Cheesy, I know… but then again, some of the friends I trust the most are those whom I rubbed shoulders with in the Army, digging fire trenches while everybody else were asleep. It’s almost the same with programming bootcamps.
In fact, I think programming bootcamps might even be more conducive for nurturing lasting friendships. First, there’s the hardship. Across two batches of students I haven’t seen anyone breeze through the bootcamp. It is at least going to be a strain on the brain sometimes. Then throw in the mix the fact that everybody in class actually wants to be there, and you start to see why it’s one great playground for making lasting friends.
Since programming bootcamps are not like universities (almost nobody cares about which bootcamp you come out from if you cannot code well), it is safe to assume that nobody goes in purely for certification. In my opinion, collective affection towards an art (programming is definitely part art) is one of the strongest forces that coheres disparate people into lifelong friendships. I’m still good friends with my batch mates and the students that I helped teach, and I don’t see that changing any time soon because many of us remain interested in becoming better engineers.
To borrow from Neil Gaiman, most of us are moving towards the same “mountain”. Along the way, we inevitably meet at the same pit stops (read: events/meet ups), and at some point I have no doubt that some of us will hitch a ride together in a company van.
4. Employability after a programming bootcamp
The question I’ve been asked most frequently is about employment. “How was your job search after the course?”, friends would ask with a mix of curiosity and apprehension. Curious because they want the answer to be “easy”, and apprehensive because they know that would mean having to take a leap of faith to start a career in a new industry from scratch.
Regardless, I always tell my friends that whether you are employable or not depends largely on the same few things:
What kind of person you are
Your background (gender, age, experience)
The quality of the programming bootcamp you attended
What kind of person you are
Do you embrace change, or prefer to avoid it? If it’s the latter, you are more likely to see every obstacle as insurmountable.
Do you believe programming is “for you”, or not? If at the end of the course you cannot convince yourself that you are a programmer, then it is near impossible to deceive an employer into believing it. The excitement of programming sits somewhere between drinking a cold beer and watching paint dry for most people, so unless it is at least on the cold beer end…
Do you have a compelling reason for choosing programming over the alternatives? If the answer is no, then you may not be happy at your new job anyway. (Most of us do not work remotely at cafes around the world.) The lack of intrinsic motivation can also affect how good you are at it.
Do you have relevant experience to bring to the company? I’ve seen friends from a User Experience (UX) background emerge from the programming bootcamp to get snagged by established startups. Another friend with advertising background managed to use her experience to land a role as a Product Manager at a technology media startup. If you don’t have prior work experience (like me), that is okay, too. Adaptability and freshness certainly have their place in tech, and can be spun into something positive.
Are you going to be a woman in tech? In Singapore gender equality at the workplace is quite good (though the ratio is still 7 men to 3 women). But this is something to consider if you intend to work in Silicon Valley or other cities in the US. Unequal treatment and sexual harassment is still a thing there. What I’m trying to say is, it can be unfairly tough to be a woman in tech in the city you’re going to ultimately work at. While I hope you never have to experience what Susan Fowler went through at Uber, just be prepared for chauvinistic assholes. A bunch of them are still out there…
And here’s a big one that few people like to talk about for obvious reasons: Are you above 50? I don’t think people in tech try to be deliberately malicious towards people who are older, but I think very few companies are open to the idea of hiring older people. Many employers, I think, reason it this way: “if I can find someone younger, it would be easier for the rest of the (young-ish) team to communicate with him/her.” They also see many young people everyday, and there is a good chance that most of their engineering team is aged between 30 to 39 years old (44 percent of the industry are, according to Singapore government data). Alas, it is also harder in general for an older person to switch careers than it is for someone younger, regardless of the destination industry.
Finally, one last but important factor that determines post-graduation employability is quality. How well does a programming bootcamp prepare you for The Real World?
5. Quality of a programming bootcamp depends on Instructor and Attitude
Quality to me is associated with two things that are intertwined:
Dedication and experience of the instructional team
Your attitude towards learning
Having something does not mean you will use it well. To get the most out of any situation, be it in a class or at a company, a positive attitude is paramount.
But let’s start this discussion by first evaluating the quality of bootcamp instructors.
Quality of the instructional team
The programming bootcamp that I attended (Web Development Immersive at General Assembly) had a terrific instructional team that comprised of a lead instructor and two teaching assistants. Our lead instructor, Jeremiah, had about 10 years of experience making games in his own studio. With that level of experience, he could teach himself web development and then teach it to us. He is also incredibly eloquent, adept at explaining complex ideas in a way that is easy to understand. The impact he has had on me as a programmer now is hard to overstate.
One of our teaching assistants, David, was a former graduate of the bootcamp, which I think added a nice touch of reality to us as programming wannabes. I used David as a benchmark of what I could be upon completion of the bootcamp. Our second teaching assistant, Rama, was a fresh graduate from the Singapore University of Technology and Design’s (SUTD) Bachelor of Information Systems Technology and Design. He brought more theoretical knowledge into the class along with an appreciation of computer systems and advanced technologies like artificial intelligence and machine learning. Both of them taught me many things, among them how to debug in every situation.
That said, it’s not always possible to find blogs that cover a bootcamp in enough detail to help you make a judgement, so this may be, out of necessity, a leap of faith. The best alternative to suss out any bootcamp is by asking your friends who have been through it. LinkedIn makes this a trivial task. (If you have questions specifically about General Assembly in Singapore, check out my detailed review.)
Quality of your attitude
Assuming you’ve found a bootcamp with great reviews, success is not yet guaranteed. A lot still depends on the student…
Here’s a short story to illustrate the point. I hate running. I’ve always disliked the idea of moving my legs faster than I care to, prancing about from destination A to B and then back to A again, all for the sake of calories and a healthier heart.
To me, getting ready to go for a run is just about the most dreadful thing possible. I would hesitate to put on my workout clothes, looking out the window to see if inclement weather could save me from doing it. Getting out of the house is hard, but the actual running would always be even harder. Only when it is over will I ever feel happy about running.
Recently I’ve had a conversation about this with my wife, and she made me realise that the problem was that I have a poor attitude towards running, and it’s been affecting how I view and perform during runs.
According to her, we live in a great neighbourhood, right next to the country’s largest nature reserve. In comparison with many others, we have it good! The air is fresh, the trees shelter our runs, and being back in nature is proven to help humans destress. My lousy attitude towards the very idea of running has robbed me of the opportunity to see and leverage what is available to me.
This is the same thing with a programming bootcamp. I’ve seen some students gripe about not having this cheat sheet or that remedial lesson, as though they are necessary if they paid attention in class and asked on-point questions!
So the point here is this: get into the learner’s mentality. Accept that practically everything is going to be new. But more importantly, understand that even though you are paying your instructors, they cannot do anything for you if you are not primed to receive it.
Sorry if I’m the one who breaks this to you, but there are no Game Sharks™ to becoming a programmer. You have to learn, apply, get stuck, get unstuck, and repeat… which brings me to my next point.
6. Good programming bootcamps teach you how to learn
The reason why it is even feasible for programming bootcamps to consistently deliver results (ie. employable software engineers) is because it is focused. Hot, electron-kamikaze laser beam focused. Bootcamps are designed to train practitioners, not scientists. If a topic is covered in class, 90 percent of the time it is because the content is necessary to help you build web/mobile applications. The other 10 percent are nice-to-haves.
I heard an interesting anecdote recently at a panel discussion in a bootcamp class about the difference between bootcamp and computer science (CS) graduates. The person who spoke said that CS grads are typically stronger in a few areas:
Writing complex algorithms that have good performance (running them takes less time and memory/space)
Solving problems mathematically
And that most bootcamps grads are better at:
Knowing what tools and libraries to use to get the job done
Understanding the implications of choosing a group of technologies (“stack”) over others
I think there is a kernel of truth in there, but I also think this is a false dichotomy. Anyone can be good at any of these things. I believe that the real point of differentiation lies in your ability to learn.
Good programming bootcamps will emphasise the importance of learning how to learn: how to find answers to problems, how to research the best stack to use for a project, how to write code that is easy to understand and maintain and so on. The really good instructors will not let you in on the answer but instead, guide you to arrive at the answer yourself.
7. Not all graduates pursue programming as a career
Here’s my final observation: not all people enrol in programming bootcamps because they want to become software engineers. A few do it to gain a complementary skill to their business. Even more do it to find out if they can do it, or if they like being one.
Most of the entrepreneurs that graduated from my batch and the one I taught continued to run their business after the course. Those who enrolled to understand themselves better, to see if they can or cannot be programmers, all achieved that goal. I guess 3 months of writing code every single day can reveal a lot of things you did not know about yourself.
Whichever is the case for you, I think these are perfectly legitimate reasons to enrol. Just take note that if you are receiving a subsidy or grant from the government, there is a good chance that you are bound to an agreement to find a job in the tech industry post-graduation.
That’s it. I hope this was useful with informing you about programming bootcamps. If you know someone who might benefit from reading this, do consider sharing it with them!
Today is Friday, 23rd September 2016, week 6 of the intense 12-week GA web development course. Each of us have just completed a full-stack web app—the first for many of us including me—and presented it to the class. It was great!
Before describing the project I worked on, I’m going to list the things I’ve learned from this week of intensive, all-in coding.
Lessons from a week of intensive coding
You won’t know until you try. Good news with web stuff is that trying is (mostly) free. (Unless you need to pay to use certain data sets from APIs…) So whenever I think something should work a certain way, I don’t ask someone. I try it out first. It is often faster and, even better, easier to internalise.
There are plugins for almost everything, so search before trying to build another wheel. The caveat here is if you are building a business and are worried about being at the mercy of external library owners (what if the creator removed it from GitHub?!), I think it’s ok to try to build your own. Otherwise, it’s best to build your stuff on what others have built.
It’s ok to leave CSS to the last, but nevertheless, do your CSS. A technically sophisticated product without good packaging is destined for failure. Internet users—everyone, basically—are human, and humans privilege vision.
To learn as much as possible, always factor some time for experimenting with things that you haven’t used or done before. Plugins, different approaches to writing code that do the same thing but potentially more effectively, APIs, etc. Walk through a door but occasionally walk back out and check out the rest. You won’t know what you’re missing out if you don’t.
Reading other people’s code is only interesting and useful at the right moment. Immediately after doing a project with the same specifications (but with wildly different implementations) is such a moment.
As you can see, I’ve learned a lot this week. I owe it to the good programming of the Web Development Immersive course and to my classmates who did their best and inspired me along the way.
Introducing Spidey 1.0
So, on to my project for the week. I made a dashboard for people who need to do research on the web, but need to do it in an efficient and non-distracting way. A live version of the project can be accessed here. Updates to the project will likely be pushed to that link.
The process of using it is something like this:
Enter search term —> Browse summarised results —> Click interesting search results to read full article on same page —> Digest info, synthesise into the project you’re working on —> Save article URL for later use/reference
Simple and straightforward enough, right? Here, if I wasn’t already 6 weeks into the web development course, I would’ve said, “Yeah, sounds simple and easy enough!” Alas, I am a month and a half into the course and I knew what I was getting myself into when I chose to try and create this project in one week. It wasn’t extremely difficult, but it was challenging.
Somehow, as a web developer, we’re supposed to know where every single thing goes and how they relate to one another. If you’ve ever looked left and right 20 times in quick succession, you’ll more or less know how it feels to create a server using Node.js.
Anyway, I feel good about how the project turned out, but if I were to be honest, I’m not completely satisfied with what it does yet. Spidey is still in its early development. It’s not good enough even for me to want to bring it into my writing workflow, even though it was designed to be. The good news is that unlike the previous project–a Spot the Difference game–I will continue to work on Spidey. I can already think of one or two features that will make it worthwhile to use. One of them that I’m most excited about is the ability to add customised markdown to your article and let Spidey find the best materials online that you should read and append as hyperlinks to your own. That should easily cut down the time needed to write a great piece by half!
I like where I am right now. I feel like some of the worst days are behind me, at least when it comes to creating a server for a web application. I know conceptually and practically how to set one up and how it works, even though it might take a while. It wasn’t easy getting here, but interest and grit got me through, and I look back smiling.
More adventures ahead!
PS. If you have seen my research dashboard project Spidey and have feedback, feel free to leave a comment.