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.
Some people like to present unit testing as something optional in addition to the code they produce. They usually talk about two options: they can either create good code or good code that comes with tests.
I just spent a couple of weeks doing TDD with somebody at work. He knew about TDD and unit testing in general, but he wasn't necessarily convinced about the trade-offs of TDD, especially for somebody with no previous experience doing it.
It will happen more often than not: after you finish estimating the work, you realize the estimates are higher than what everyone was expecting.
Great, capable individuals can definitively make a difference. I know a lot of them; sharp, hardworking people that could easily impress you with their knowledge after a 5-minute conversation with them.
Before sending an estimate for your next project, take some time and consider the following questions:
If you do a quick Google search for how to get better at estimating software tasks, you'll find multiple people recommending the way they do it. Some of these recommendations are some variation of the following ideas:
It's being a long time since I estimated something using a single value. Providing a range is usually a better practice, and forces a different thought process that's extremely valuable.
Are these the same really? I know that mathematically they are, but do they represent an equivalent effort for your product?
Where would you rather invest your time? Upfront to try and come up with a more accurate estimate, or throughout the project to manage around an inaccurate estimate?
"Prioritization" as in having a conversation regarding all the tasks assigned to the team and coming up with the best plan to achieve our goals.