Great developers spend much of their time writing code. It’s not only about how much they study, read, and keep up with the latest trends but how much time they dedicate to hone their craft. They constantly make things. Again and again.
I've written before about code clarity, but I don't think I paid enough care to the importance of naming things.
When working on a product, it is good to have an understanding of what each stage of completion means. For different teams, these concepts will vary, but this is the way I like to do it:
One of the biggest complaints about the Scrum's daily standup meeting is that, more often than not, they become "status" meetings.
We made a lot of progress in our product over the last two weeks. It was a bunch of work, and it took nights and part of the weekend to get where we are right now.
As soon as some of the stuff reported in the backlog stops being relevant, the whole thing becomes useless and distracting.
I understand some people have a different way to get to the finish line. Mine has evolved. I'm still a work in progress, but it's evident where I stand nowadays: I care first and foremost about putting something —anything— out there, perfection be damned.
A common saying that goes around is that a good leader "gets out of the way and let their teams do what they do best." I like it. I've also said it before.
A long time ago I wrote about how I felt about comments in my source code. It was back in 2010, but I'm not going to link back to those posts because I wrote them in Spanish. If you are sufficiently motivated, feel free to search the archives.
I always wanted to go to a US college, so back in 2015, I started my Masters in Computer Science at Georgia Tech, and just this month of May 2019, after a lot of work and effort from my entire family, I graduated with a major in Machine Learning.
Here is kind of a cheezy advice for a new manager, but one that I found quite useful as I got more leadership responsibilities a few years ago:
After four weeks of working full time with AWS, I have mixed feelings about the current state of cloud development. This is a great time to develop enterprise applications in the cloud: AWS (and Azure, and GCP) makes so many things possible — things that were complex before. You can quickly stitch together services and create a sophisticated, integrated system with much less effort than before.
There's an Amazon S3 bucket that we need to monitor to process files copied into it. Doing this is pretty straightforward by invoking a lambda function whenever the s3:ObjectCreated:* event is triggered by S3.
People applying for an open position at your company are much more than what their resumes say. They are more than their education and experience. They are more than their ability to answer questions under pressure or make a first good impression.
If you are into Reinforcement Learning, it's very likely that you've heard about OpenAI Gym. It's an amazing platform that you should check out in case you haven't heard about it.
We all do the same thing: plaster our resumes with every single detail we know or ever heard mentioned. From the most critical technology stack to the smallest recondite tool, we always focus too much on the tools we can handle and forget something much more important.
Yesterday Nelson asked me what exactly motivates me to do what I do every day. A loaded question that made me think for a bit.
This article is supposed to be different from the one I posted a few days ago: A quick guide to get started on Machine Learning and Computer Vision. That one is more of a collection of resources that focus mostly on getting up to speed on Machine Learning and Computer Vision, but it lacks the story part. You know, when you don't know where to start, sometimes you need somebody that guides you step by step from the beginning and doesn't throw you in the middle of a shitton of resources.
Jeff Dean, the lead of Google.ai, Google's AI division mentioned that Google was able to replace 500,000 lines of code from Google Translate with only 500 lines of TensorFlow.
Assuming you are starting from scratch, here is a short list of resources that will get you started. They are organized by level of complexity, and they cover both the general aspects of Machine Learning, Computer Vision, as well as more deep technical concepts and algorithms.
At the time of this writing, the TensorFlow Object Detection API is still under research and constantly evolving, so it's not strange to find missing pieces that could make the library much more robust for production applications.
(I've got to say that this was meant as an internal memo, so there might be references that will sound weird for people outside my company.)
I've seen people spend a lot of time crafting notes for their teammates to document the right order of steps to accomplish a repetitive and cumbersome task.
Putting extra effort is a good thing. Going above and beyond is also a good thing. I think you should try regularly.