Just over a year ago, I wrote about the lack of diversity at Made Tech and how it was something we needed to work on as a business. We’d recognised our ‘ignorance’ had led to inactivity in identifying problem areas, but once we’d accepted our failures, we had to stop being passive bystanders and actually take active steps to address them.
Coined by Cal Newport in 2012 on his Study Hacks blog, deep work is the ability to reach a state of increased productivity when performing cognitively taxing tasks by minimising or ignoring external interferences. Making deep work the centrepoint of your knowledge work schedule generates three key benefits:
Made Tech is where we are because of our people. We see the importance and value in progress and self-improvement and encourage a culture of openness and sharing because it creates an enjoyable and productive environment. With learning at the crux of everything we do, we wanted to improve software delivery within our own organisation first and create capable mentors to help everyone in the team progress.
We therefore decided a new approach to employee development was needed. The idea was to provide clear paths for improving ability both internally and in customer teams. While reviews and continuous feedback systems work on a general level, we wanted to find the most effective way of increasing skill parity across a company, so we trialled a skills matrix.
In August, one topic sparked a lot of debate on the internet in general, and in the Tech industry in particular: the so-called “Manifesto”, written by James Damore, then engineer at Google. While this blog post won’t be about the manifesto, some events that occurred after it came out prompted me to write this. But before looking into it, let’s go over some of what has been said and written since then.
React is a fantastic tool for building frontends. We’ve been using it for small applications for a while, and recently used it for a more complex app. Given the library, and the mass of libraries you’ll use with it, are still brand new, we encountered many architectural and code challenges throughout development which haven’t been solved before.
In the last 10 years, the web has grown quickly from a document-only platform to full-scale applications. A good chunk of the applications which are now being developed are no longer native, and are instead relying on the web.
At first glance, it is easy to believe that programming as a profession is one which is both in rude health, and for which the future is incredibly bright. Increased automation, the mind bending world of machine learning, and the ever more intuitive ways in which software impacts our lives all suggest that programming is the career to be in, and one of the few careers which one can safely guarantee will still be around in 50 years irrespective of automation or many of the other issues that threaten the future workforce.
The Don’t Repeat Yourself principle is probably one of the most widely recognised software design patterns out there; most beginners in the industry will have heard of it, and more seasoned engineers will have taken it further and see its use in other design patterns such as Service-Oriented Architecture, Inversion of Control and Composability over inheritance.
At Made, the majority of our projects use Continuous Delivery pipelines to provide a clear path for deploying to production. It’s common for these to be setup on the first day of a project kick-off.
We’ve been running internal Code Dojo sessions for a couple of years now, and last year our newest member, Andrew, suggested putting a new spin on the traditional format. We enjoyed it so much that we had to share it with the wider community so, to help celebrate our move to a swanky new office, we’ll be opening our doors to the public and launching Made’s first monthly event: QuizBuzz!