Projects which are built by teams of developers and that take months to build, need to be easily maintainable. They should be easy to understand and follow as much default conventions as possible. Why? Teams change.
How do you prepare a project for changing teams? Stick to the most common standards and use boring technologies. So if you use Laravel, do not introduce an additional architecture on top of it. It takes more time to build this architecture, and every time a new developer joins the team, you need to teach your way of doing things. It takes time until they become productive, and if a deadline is near, you miss the opportunity of outsourcing a feature to a freelancer to get everything done in time. The custom architecture requires time to learn, and this is exactly the resource you don’t have at this moment. Goal failed.
I am of the same mind as Sebastian. When I started with PHP, no frameworks existed, and as soon as I tried one, I was immediately hooked because of the advantage that any developer anywhere in the world, with knowledge of the framework, could jump in on day one and know what is going on. As soon as you start changing the defaults it adds even more overhead to the whole codebase.
It’s like going to your regular grocery store. It’s comfortable, you know where things are and can be in and out without much fuss. Then compare that with being on vacation where you have to visit a new grocery store. You can’t find anything, what typically takes ten minutes now takes thirty, and it’s super frustrating.
Sticking to the defaults also pays dividends on projects that are not long-lived. I have apps that are many years old that still work and only require the occasional bug fix. Because I stuck to the defaults I can quickly jump in, make the fix, and go on with my day. In apps where I’ve changed them, it feels like it takes half the day to relearn how it works and why it works.
There are two trains of thought on the question of should you deploy on a Friday. One believes you should deploy on Friday’s because if you have a sound system in place, you can always roll back, the other thinks it is not worth the risk.
Both of these people are correct, and if you have a complete automated deployment process complete with rollbacks, and the rollbacks are continuously tested, then sure go for it. But in every other case, I don’t think the risk is worth it.
If it’s an emergency sure, but I’ve rarely found a deploy to be so important, it’s worth disappointing my wife and kids if it goes wrong. The risk/reward is just not close to being worth it for me. Work can wait.
Be kind. Yes, a person is not their code, but writing code is a creative act. Creators are by nature intimately involved with their creation. You’re going to be critiquing another person’s creation, at a minimum, be kind when you do it. Better yet, find positive as well as negative things to say. We want both the code and the coder to be better once you’re done; don’t make it easy to reject your constructive observations by being a jerk about it.
Lot’s of other great advice in the linked document, but this one really resonated with me.
Today I hit an interesting problem and when creating a report for an internal billing system. The system itself automatically bills each customer every year and we have two types of customers. One that pays with a credit card through Stripe, and another type that we invoice and their billing departments pay.
Because invoices take longer for us to be paid we always create the invoice 30 days before it’s actually due and for Stripe customers, we do it 7 days early. This way if anything goes wrong like a declined credit card it gives them extra time to fix it before becoming delinquent.
Of course, the side effect to this is it causes our stored “next billing date” to be 7 or 30 days off depending on the type of customer, and we keep the original date in case the customer ever decides to switch from one to the other.
With that setup out of the way, I needed to create a list of customers ordered by when they would be billed. Like all things, there are many ways to solve this but for this, I decided to do it directly through SQL. What I wanted to happen was if an organization is a Stripe customer then creating a “real_bill_date” set to 7 days before it’s due, otherwise create a “real_bill_date” to 30 days prior.
Here is the query I was able to create:
organizations.stripe_active = \'1\'
DATE_SUB(next_bill_date,INTERVAL 7 DAY)
DATE_SUB(next_bill_date,INTERVAL 30 DAY)
END AS real_bill_date,
subscription_active = 1
This uses SQL WHEN/ELSE clauses to determine what should be happening. Basically translating into “if Stripe is active, then subtract 7 days”, “else subtract 30 days”.
This is useful for the next time you think you have to do a query and then do a query looping each to get a calculated field. Yes, that typically works but is process intensive and can lead to timeouts. Doing it directly through SQL is usually much faster.
In the podcast, he talked about how PHP felt more “libertarian” in the early days. The underscore represented that this should be protected or private and even though this is a recommendation from the creator of the code, you are an adult, and if you want to do something with it, then you accept the risk.
The language and community have since switched the stance, and now everyone wants to restrict it with the feeling that if it’s code you are writing, then you know best how it should be used.
I’m not sure one way is better than the other, but as I mentioned in the tweet, I miss the old days.
This will be the third year we’ve been running Laracon Online and I have learned a lot about selling tickets in the process. Based on this tweet I was reminded of how we’ve reworked the order system over these three years and I wanted to share with you the progression.
The first year we used a third party service to sell tickets. For the percentage they would take we assumed it would be a decent deal for us since we wouldn’t have to build out any of the infrastructure. However, I was swamped with support that year. I had hundreds of people entering their email addresses wrong and other weird stuff. It was a nightmare.
From this point we decided we would build our own system for the next year and I tried my best to build the simplest system possible. You hit the /pay route, added all the emails you wanted to buy tickets for, entered your account info, and pay. Behind the scenes we would email all the people and tell them to reset their password to create an account. It was simple and worked great.
Now that we had all this data for this year I was brainstorming on how I could make it even easier for people to purchase and I came up with the idea of just pre-filling the checkout system with all the people you purchased tickets for last year. So if you work at a company buying tickets for 20 people all you have to do is confirm they all are the same and hit buy.
Thinking through all this took some time but the implementation was really straightforward and only took me a night of hacking.
As developers we want to focus on the code and think about how to design apps that are easy for us, but our focus should always be on the end user. Even if it adds complexity or makes our app harder to manage later. The customer is the priority and making their life easy is why we are here.
Everything is always a trade off, just make sure you are prioritizing what is important.