menu
Friends of ThoughtWorksFriends of ThoughtWorks

Friends of ThoughtWorks

Hello from ThoughtWorks

We'd love for you to join the Friends of ThoughtWorks SEA community!

 Being part of this network will give you a first look into our tech insights through the sharing of articles, videos, and access to our events. 

Meet a ThoughtWorker

David Tan Friends of ThoughtWorks
David Tan Friends of ThoughtWorks

A little bit about me...

Hello! I’m David.

I started my career as a software developer with ThoughtWorks in 2017, after I graduated from a coding bootcamp with General Assembly. Through the year, I've worked with and learned from some super awesome folks, and I’ve learned several lessons have helped me grow as a software developer and human being. I feel remiss if I don't share this with the broader community. So here it is, and I hope you find this useful!

What I Learned in 2017 about Learning

Lesson 1: Do one thing at a time

When learning something new, I found that it almost always came with a motley crew of related tools. It’s like taking your boyfriend out on a date hoping to get to know him better but then all his friends and family and aunts and uncles come along. These are all good things/people that serve a good purpose, but right now they are just distractions on this date, and if they come along you’ll never get to know your boyfriend.

So, for example, if I’m learning automated configuration management with Ansible and I need a virtual machine to run my playbook against, I’d just manually bring it up on my cloud provider of choice, add “Learn about automated provisioning” and “Learn how to use Vagrant” to my to-do list, and then focus on learning Ansible.

Lesson 2: You can do a lot in 15 minutes

A ThoughtWorker in Bangalore shared this lesson with me and this has changed my life. In 15 minutes, you and I can do one or more of the following — write a unit test, write a function for our side project, update a README, commit code, write an outline for a talk, or read about some topic.

I used to think that coding was something that needed at least an hour of undivided attention, but now it’s something that I can do in the morning before I leave the house, or with some spare time after lunch. I was able to work on my side projects, thanks to this guy’s advice. (Thank you Jayant!)

Lesson 3: Feedback is good for you

In ThoughtWorks, we have a strong culture of feedback. I ask for feedback from my pair after we’ve paired for some time or after I’ve conducted a lunch-and-learn session. We also have team retros internally and with our clients. The feedback has helped me save mental resources from worrying about things that didn’t need worrying, and that frees up mental space for me to work on the things that I need working on.

My colleague once commented that feedback should be pull-based. This resonated with me. There are various reasons why someone may not take the initiative to give you feedback — perhaps they don’t want to sound preachy/know-it-all, or perhaps they don’t know whether you’d be offended. So the onus is on us to ask for feedback if we want to improve. (That said, nothing is stopping you from asking if you could give someone feedback if you think that would benefit him/her.)

Lesson 4: Avoid the “all-you-can-eat buffet” anti-pattern

As a junior developer, I was found myself confronted with an endless stream of things to learn. Docker! React! Serverless! Angular! Rust! Neural networks! I initially tried to learn everything, and I found that the things that stuck were those that I could (i) apply on my project or (ii) apply on a side project.

I wasted many hours learning things that I soon forgot because I didn’t apply them. This is a waste of time because it doesn’t create value for myself or people around me. I could have spent on some other topic or fundamentals that would have been immediately useful.

So I would call this out as the “all-you-can-eat buffet” anti-pattern which we should avoid. It’s similar to all-you-can-eat buffets in several ways:

  • We’re wasting valuable nutrition because our body is physically incapable of absorbing that much at one go
  • We’re wasting time/money eating more than we should, when a simple meal would suffice
  • If we eat like it’s gym day but don’t hit the gym, we’d get obese and unhealthy, rather than nourished

“Information in context, trumps instruction out of context.” (source unknown)

Lesson 5: Don’t rush

Peter Norvig wrote a nice article on this. Efficiency != effectiveness. The number of YouTube videos or books I can read != internalized knowledge which I can retrieve and apply.

We are not computers. We can’t absorb knowledge like how we install packages. I find it helpful to think of my craft with a physical analogy, such as learning to play the guitar, or playing tennis. Nobody can master these things in a few months. Give yourself time, keep deliberately practising the rudiments and etudes, and you will get better.

Once I was cycling to buy breakfast and I couldn’t look at my phone or listen to anything. And I accidentally realised that was an excellent time for me to reflect about what I learned the day before. In our culture of endless distractions, I’ll try to make an effort to unplug and just digest what I had learned that day.

Lesson 6: Prioritize by deprioritizing

Manage your time and energy. Help yourself do what you want to do, by eliminating things that you know you shouldn’t do at this moment.

Lesson 7: Keep your own kanban board with clear story cards

Kanban board has been a useful tool for my own learning and growth. I find it has several benefits for learning:

  • It removes the overhead of remembering what I need to work on
  • It makes it easier to learn things (just pick up a story and go)
  • It gives me a place to put things which are useful/interesting but which are not a priority for me right now. (see Lesson 6)
  • It helps me break down an epic (learn deep learning) into a series of bite-sized cards that I can finish one at a time (e.g. read chapter 1 of book X, complete tutorial XYZ on data normalization)
  • It gives me a sense of progress
  • It documents my learning journey and allows me to easily retrieve and share resources with people.

Personally, I find that clearly written cards help. Each story card is essentially an instruction for you, from your past self. Imagine somebody wrote you this reminder: “Buy gifts”. You’d be scratching your head, right? What gift? For who? When? What specific gift? Why? With all these things to figure out, it makes it easier for our brain to procrastinate. Yet I find myself writing unclear instructions to my future self (“learn networking”), and my future self procrastinating on learning something because too much mental effort was required to figure out what needs to be done.

Lesson 8: Read technical blogs

For articles and blogs, I use Feedly as an aggregator to follow technical blogs. When I encounter some useful article, I’ll add it to my Feedly list and I get to read more of the same articles from the same writer(s). I add my mailing list subscriptions too (e.g. cron.weekly). If I’m going to be addicted to scrolling mindlessly through my mobile device, I might as well be reading something useful.

Lesson 9: Don’t miss out on great talks

While writing this article, I chanced upon two “awesome lists” for programming talks: this and this. I’ve watched a few videos (like this one — about how to master or get good at programming). I think watching these videos are great, convenient, relaxing and low-cost way to explore the known unknowns and unknown unknowns. Watching these videos as a team could also make for a great weekly lunch-time activity :-)

Lesson 10: Write Code

I remember that in one of my projects I had preferred to pick up DevOps-type stories instead of dev stories because I wasn’t strong in programming paradigms and I didn’t understand the codebase well. As a result, I had missed several opportunities to learn and practice good object-oriented code, testing strategies, design patterns, etc.

Using a unit testing metaphor, as software developers, we all have a hypothesis that we’re good software developers. We have to test this hypothesis by writing code. When the tests fail, we realise that the assertion is not yet true, and we go and do the necessary to make the assertion pass.

Lesson 11: Teach / share

I was fortunate to have several colleagues who are interested in machine learning, and I was able to learn a fair bit about machine learning by preparing sharing sessions on machine learning topics. Preparing those sharing sessions was again a kind of feedback to myself — e.g. I don’t know how to evaluate models, or I don’t know what data normalization is — and having to share about X was an excellent opportunity reason for me to first know X :p

Getting these ideas out of my head was an excellent way to eliminate the illusion of mastery.

Lesson 12: Be healthy

Exercise, sleep well, eat well, take regular breaks, build good habits, don’t be addicted to social media and/or fruit ninja.

Lesson 13: Better than yesterday

"The greatest teacher, failure is." (some movie character)

Learning something new always involves some amount of failure. Learning how to skate requires you to fall a few times. Asking questions that seem basic can certainly make me feel like a failure sometimes. Embrace failure and we will grow. Avoid it and we’ll let pride prevent us from becoming a better and more knowledgeable person.

This page from the Passionate Programmer really resonated with me. Chad Fowler says it better than I can, so I’ll just quote him here:

"You also need to be happy with small amounts of “better.” Writing one more test than you did yesterday is enough to get you closer to the goal of “being better about unit testing.… If, on the other hand, you decided to go from zero to fifty tests on the first day of your improvement plan, the first day would be hard, and the second day probably wouldn’t happen. So, make your improvements small and incremental but daily. Small improvements also decrease the cost of failure.

… One of the great things about this simple maxim is that it can apply to very tactical goals, such as finishing a project or cleaning up a piece of software, or it can apply to the very highest level goals you might have.

How have you taken better action today for improving your career than you did yesterday? Make one more contact, submit a patch to an open source project, write a thoughtful post and publish it on your weblog. Help one more person on a technical forum in your area of expertise than you did yesterday. If every day you do a little better than yesterday toward improving yourself, you’ll find that the otherwise ocean-sized proposition of building a remarkable career becomes more tractable."

Conclusion

I hope these 14 lessons have been / will be useful for you. 

Originally posted on Medium

Related post: What I learned in 2017 about writing good software

Stay up to date on what's happening at ThoughtWorks SEA!

Join our Friends of ThoughtWorks community