Harry Bailey works directly with agency leaders to improve how delivery works — helping them understand what's driving overruns, rework, and delivery friction, prioritise what to tackle first, and build the habits and ownership that make improvements stick. With more than twenty years in project delivery, agency leadership, and operational change, he brings hands-on support to the people and practices at the heart of how growing agencies deliver.
When you set up an Apache or LAMP Lightsail instance on Amazon Web Services, the default document root is /home/bitnami/htdocs/
If you are migrating to Lightsail already use something other than htdocs as your root folder, for example public_html, then you might want to update this.
Although you could creating a new app on the server to hand it, here is a simpler option which leaves the default folders and setup in place:
In /opt/bitnami/apache2/conf/bitnami/bitnami.conf add your own document root to the end of every location that htdocs is mentioned.
There was a manager I worked with recently who was having serious trouble with their onboarding process.
Working with several teams of between 5 and 8 developers, the business was growing fast and recruiting at all levels. Some of the recruited developers were straight out of a code academy, with minimal experience of working in a team, on a regular release schedule, or with production code.
These less experienced developers were their primary challenge. The one they thought could release most value. But how do you get a developer enough experience to graduate them to being part of a team? How many of these developers can you put into a 5 to 8 person team and the team support their learning and progression so they might become independent? How do you introduce them to the team? What does the average day look like for one of these developers while they learn the ropes?
We’ve all worked with developers who prefers to get on with their coding alone. They’ll assign themselves a large set of tasks, tell everybody they’ve got loads to be getting on with, put their headphones in and you won’t hear from them for several days.
They might pin their name to a key change or issue, make all the required decisions alone and get it ready for deployment in record time. They may even be able to resolve complex issues with infrastructure or libraries, but not have the time to share those processes.
You likely know these type of developers by the names Ninjas, Wizards, Rock Stars, or 10x. These are terms of endearment used in praise of the activities above, or even in job advertisements looking to recruit developers with these habits.
What these behaviours actually do to your development team could not be further from a positive outcome.
Don’t get me wrong, the short term progress can be impressive. So impressive in fact that managers, and often less experienced team members won’t be able to help but praise our False Hero. Speed is always seen as a good thing in a word of complexity and deadlines. Solo progress without the need for peer input is often seen as something to aspire to.