A few months ago I moved the sidebar in my code editor to the right and I love it. In fact, I’m sad I’ve been writing code for 20 years without ever doing this before. If you’ve never tried it, you should and here is a video by Jeff Sagal demonstrating why it’s useful:
I have all of my editors, that allow it, set up this way and I don’t think I’ll ever go back to a left sidebar again. Look at how beautiful VS Code is, and no janky code moving when you open it.
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.