Culture is a word that is thrown around so much within our industry that it has become a parody of itself. From bizarro world news stories such as Dropbox’s cafeteria gaining a Michelin star, to the ping pong tables that are eternally associated with a tech office, it is often assumed that tech companies, and in particular startups, are innovative by default.
Made Tech Blog
Technical challenges with adopting Continuous Delivery
I spoke last time about the organisational challenges of adopting Continuous Delivery. One of the key takeaways was the importance of blurring the boundaries between team ownership in order to facilitate better adoption. This time around I want to zoom in a bit and focus specifically on the challenges faced by specific parts of the pipeline. Depending on how far through adoption you are, you likely no longer have dedicated teams for each of these functions, though the problems outlined here can still exist and derail even the most cross functional of teams.
Building a Continuous Delivery Pipeline in 5 minutes
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.
Introducing our new monthly meetup: QuizBuzz!
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!
9 Benefits of Test Driven Development
Test Driven Development is the practice of writing a test for a piece of required functionality, before writing any implementation code. This test should fail when first run, and then, you write the code to get it to pass. It doesn’t have to be the most perfect code, just so long as the test passes. Once it does, you can then safely refactor your code.
When to avoid the DRY principle
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.
7 Problems to Avoid When Building a Software Team
Building and maintaining a high performance software team is an ongoing effort. The challenges range from attracting great people in a highly competitive market, to providing interesting and challenging workloads, and putting together team structures and practices in which people can thrive.
Why be defensive about programming?
Programming style is often categorised by language or architecture, but the code style also can differ a lot within the same kind of architecture. Defensive programming is derived from the notion that very few things can be trusted when running a program, and adding more checks help to improve the stability of it.
What makes a great Tech Lead?
If you’re a developer trying to understand what may be required to take a step up, then you’ve come to the right place. In this article, we’ll discuss a few of the traits that we look for when hiring or promoting into Tech leadership roles:
How to Create a Better Rails Development Environment with Docker Compose
I’ve seen quite a few articles recently detailing the steps to creating a simple Ruby on Rails development environment without Vagrant. I’ve found a few issues with these that make the environment somewhat unfeasible for real use. Hopefully, by the end of this article you will have a Docker-based development environment that can actually be used for real development.
Get our latest blogs with our monthly newsletter. Subscribe now