Now I know this is um dot CSS. So I should really be talking about some hardcore sass, or maybe some really intricate CSS architecture. But one thing I’ve learned is that it’s really important every now and again to just leave our tool to learn, step back and take a much broader view of what we do.
So that’s why I’m speaking about these principles, they’re personal principles of mine – these are things that I do when I work and every bit of work I do, regardless of the technology, the stack, the tools I use tries to follow these principles. They’re very new. I’ve never shared these before. So if it interested to see what people think, but that’s I kind of that’s kind of thing, I’m going for today, less about tooling more about approaches so yeah, my name is Harry.
I’m a consultant web developer. That means that I spend a lot of time with a lot of different clients. I travel around a lot and learn about everybody’s problems. I’m like a developer therapist in doing this. I’ve realized that it doesn’t matter what stacks our company uses. It doesn’t matter what which preprocessor they’re used. They always have similar problems that can’t always be solved by specifics, and it’s really important to know specifics.
It’s good to know, flexbox why it’s valuable to know about SAS, it’s very, very valuable, to know different technologies, but specifics aren’t always that transferrable. One thing I’ve learned in the last few years, especially working for myself as a consultant, is that code is actually only a tiny, tiny part of what we do think about what you do. In your your day to day life, you might deal with clients, you might spend a lot of time discussing compromises with designers.
You might spend a lot of time explaining why things can’t be done to project managers. The actual code you write is a tiny, tiny part of your drug, so I think it’s important to realize that you know focuses, should shift and mind shifted a few years ago and much much for the better. I found that on a more effective developer, by ignoring the specifics and trying to focus on principle LED approach to development.
The interest is now anyone’s thoughts on this. So if you want to tweet during this talk, I’d be really grateful, so I’ve just 10 CSS will do. I know it says you know, principles for front-end development, but I only really write CSS. So all of these principles I applied directly to CSS start off with an easy one. The simplest option is usually the best. I got Hugo who’s speaking a little later to do some translations.
For me, if they’re wrong, it’s his fault, the simplest doctrine is usually the best. This seems quite obvious right. Let’s start with an obvious one. The simple option is probably the cheapest to implement the quickest and cheapest option to implement will be the simplest one. This is good for business and we’ll talk about business in a second that’s another one of my principles, but quick and cheap to implement is really valuable and it’s also easy for other developers to inherit.
When you pick up a system from someone, it’s really complex and over-engineer, that’s a horrible thing to try and work with, so always err on the side of simplicity. If you’ve got two or more options, two or more solutions to a problem, all let’s try and pick the simplest, it’s less likely to break it’s probably more robust. It’s just locks easier to work with also lessens the amount of cognitive overhead when working with a system.
It’s a really horrible thing to have to try and remember every moving part in a system which leads men to the next bit, always try and reduce the amount of moving parts in a system as a developer. It’s very easy just to do as you’re told, or it’s very easy to build the features that have been requested. I think it’s really valuable to say no to a lot of things. The best code is no occurred at all, so it’s a really good exercise for developers to get rid of unnecessary stuff.
Anything that could be removed from a project try and get rid that could be features in. I could be telling a client that you know we don’t really need this feature, let’s get rid of it or it could be actual lines of CSS. It could be reducing a 20 line mixing down into a single helper class right. Removing the amount of moving parts is a really valuable exercise. Every moving part in a system is a potential thing to go wrong.
It’s a potential point of failure. Everything you add to a system introduces the risk of something going wrong. It’s easier to men attained a system with fewer moving parts. I think it’s a really valuable exercise to get rid. The third principle understand the business now. In this context, the business could mean a few things. If you work for an agency, the business would be your managers and the client the person funding the project.
If you work in honks, if you work for a starter for a product like Kayla, get the financial times, the business is where you work every day, you’re surrounded by the business understand the business makes you a very valuable developer. It’s important to understand that every bit of work you do has a cost and a value associated with it. Try and understand the financials. I don’t mean you know, learning what your colleagues salary is, but perhaps knowing what the company charges you out on for a day right.
It makes you much more effective understanding. The cost and value of your work means that you can make very very informed decisions about what you do for the good of the company. Don’t waste other people’s money. I like to also make you a much more valuable developer. Imagine a company looks like this and you’re just a developer, you’re, not better than anyone else, you’re, no cleverer, no more important anyone else and unfortunately you’re, probably quite replaceable.
If you look around you right now, there are hundreds of people in this room who all do similar jobs so being a regular developer. Who just does their bit of the the task, isn’t necessarily a very valuable developer to have. It sounds really cruel, but I do believe it’s true um, so, instead of having this position within a business, try and have this position trying to connect yourself with everyone else’s problems, understand the cost and the value of your work.
It makes you much more valuable principle. Number four care, laughs and care appropriately. Another thing I learned in especially my time working in big companies. No one cares about your kurd more than you do. Your client doesn’t care if you’ve used SAS or less the business doesn’t really care. If you used an inline style or not, don’t stress too much about your own work and pick the right battles for everybody else, there are a lot more people working on that team than just you.
When you have. Whenever you have discussions, you have to balance everybody else’s needs and wants remain objective. When you do this care less about your own work and care about the good of the team, the stakeholders there’s a much bigger picture out there. The bigger picture looks something like this: we have the user, the person who needs the product you’re building the team. That would be you and your colleagues, designers developers, your solutions, architects, UX guys and then there’s the business.
The person funding this project. Now I’ve worked with a lot of developers who think in this degree they think about the team. They make decisions for the team. They want to use a preprocessor, because this is one we want to use good developers a bit like jugglers. Good developers will think here. The overlap, but great developers think about everybody else’s overlap. Great developers are very unselfish people, and I’ve found this in working with different companies that the most productive teams are the people who make sacrifices themselves for the good of everybody else, so care less about your own work and care more appropriately about everybody else.
The fifth of the ten principles – pragmatism, Trump’s perfection – it’s better to have good enough working today than it is to wait for perper for perfection tomorrow, get things alive. You’ve always got time to make things better. Perfect is a real real sort of misfire on the web. Anyway, think about all the different browsers devices network connections, we will never achieve perfect, so it’s not there’s no point even trying.
I worked with a client who delayed a release by nearly two weeks, because the color of the nav highlight was wrong. That’s insane! That’s! That is a you know, that is a very soft edge case thing to happen, but that’s expensive missing out on potentially two weeks of new signups, because the nav was slightly the wrong. Color is expensive users, don’t care if they’re now slightly the wrong color, because they never saw the PS DS, pragmatism, Trump’s perfection, something hacky that works today is better than something perfect that might work next week.
Never hold yourself back in the pursuit of perfection because it just slows teams down thinker, product level right. Some of these principles seem fairly interconnected. So this is a little like think about the business, but thinking up product levels, a really valuable thing for a developer. To do there’s a very sort of old but harmful view that as CSS developers, it’s our job to build PS, DS and that’s really harmful, because that’s not true at all.
We’ve got to think about the performance of occurred base. We need to think about the maintainability. The velocity of the team we’ve got a lot more to worry about than we realize so try not to put yourself in a bubble and figure out the entire product you’re in a very, very valuable position if you’ve started understanding the business and you’re a developer. So you understand the technology, you can make great decisions for that product.
True story. I once worked a company where a simple UI decision that I made save that company hundreds of thousands of pounds – it’s too long, a story to get into now, but you want to hear it over a beer I’ll. Let you buy me a beer, but yet we’ve got a profound ability to, in fact affect not in fact affect entire product. Use that wisely do what’s right for everyone. Seven do not design systems around edge cases.
I encounter this one quite a lot. Basically, don’t let the minority lead, the majority do not bet your entire product around statistical outliers or another example. For you, I worked with a company that was making a mobile website a mobile web app. They needed a spinner right, a little loading spinner. Now we had to accommodate a really old flavor of Android and a really old flavor of blackberry.
Designing systems around edge cases is a really expensive thing to it can hold the quality of the product back solve every edge case as an edge case. Don’t let it leak in and influence the entire build of a system number eight another. Quite specific one. Don’t make decisions based on anecdotal evidence, another true story: I worked with a company who they really should have been using a preprocessor.
They had a big, a big UI and it would have really benefited from using SAS, and I got that I asked them. How can we don’t use SAS and the response was? Oh someone told me that variables don’t work very well in SAS. Well, of course, they do. Tens of thousands of people use sat every day, of course, variables working SAS. Did you not think to try this out yourself and they hadn’t they hadn’t fought to run their own tests.
They trusted a story. They trusted some box. I never trust stories, always trusted data. It’s very expensive to ignore the numbers. Another example you’re going out to eat a restaurant and you find a hundred five-star reviews for this place, and then you see one two-star review. You will obviously ignore that two-star review. The two-star review is a statistical outlier, get rid of anomalies, always trust numbers try and avoid trusting anecdotes and stories.
The ninth principle don’t build it until you’ve been asked for it. It’s really tempting, especially as a CSS developer, I’m speaking personally here to over-deliver. It’s really cool to say: I’ve made this mix in which does this, but if you pass in this parameter it does this. The problem is no one’s asked for that. So I’ve spent the business as money. I’ve made something that I haven’t paid for. I’ve spent an extra half day, sugarcoating some some sass, no one’s asked for that, but someone’s paid for it right.
So it’s a rephrasing of yeah. You ain’t going to need it. The the programming software engineering principle and it’s really valuable to try and follow it, can be harmful because you have the cost of the initial work upfront. If someone hasn’t asked for a feature, don’t build it because you’re spending someone else’s money, but also it can influence the rest of an entire project. If you build something now that has a certain dependency on a third-party library, your product is now hooked into that dependency.
So it might have a knock-on effect with future features. You want to add um and yet maintaining things that no one even wanted. Imagine having to tell your manager that I had to bug fix something, or what did you have to bug fix? You don’t really know about it, cuz, no one asked for it, but I built it anyway, and I’ve spent two days fixing it it’s a very unwise, irresponsible approach to building websites don’t build anything until you’ve been asked for it solve every single problem.
Only when you encounter it, you might be well aware that you need to support international ization in six months time. Do it in six months time, don’t do any work ahead of time expect and accommodate change. If this is the one thing that any sort of large-scale site developer should always try and do expect and accommodate change, I’ve been doing this long enough to know that clients will throw you a curve ball.
The business will make unusual decisions. Users will request odd features. Everything is subject to change, so expect it and accommodate it. Every bit of code you write, make sure you can undo it next. You can reverse decisions, keep yourself free to change direction, never tie yourself down, never put yourself into a corner. You can’t out of everything. Is subject to change so at least accommodate that, and you can use this as a really good way to just lessen the stress.
I get a lot of workshop attendees asking me: oh, we really struggle to find the right name for something. You know we spend a lot of time thing about the right name for something my advice is always pick something now right worry about something that fixes a problem right now, because they’ll probably change anyway, don’t try and predict the future always make make sure that you Can change direction, undo things and modify decisions that were made months ago because you’ll thank yourself in the long run? So just a recap, my ten principles, my 10 personal principles for effective front-end development, pick the simplest option.
It’s the quickest and the cheapest to implement it’s the easiest one to maintain its own, that’s least likely to go wrong. No one appreciates over-engineered kurd a website is not the place to show off, reduce the amount of moving parts, remove the amount of moving part from a system so that it’s more robust, more things going on in a system means more things that could potentially go wrong. It’s a really good exercise to develop as a developer, to build less.
The best code is no code at all. It’s the fastest. It’s the most robust. It’s the easiest to debug. Understand the business be aware of the fact that everything you do has a cost and a value associated with it be responsible with other people’s money. It makes you a better developer in terms of actually writing CSS, but it also makes you more employable more valuable. Member of the team, if it can be less selfish and spend your employees money wisely, you will get more effective products off the back of it and they will appreciate that work, care less and care appropriately.
When no one cares about your CSS more than you do. Stop being enclosed in a bubble and think about what you can do for everybody, pragmatism, Trump’s perfection, don’t be the guy who holds back, or at least for nearly two weeks, because the nav is slightly wrong. It’s expensive! It’s unwise and it doesn’t help anyone hacking something together. That works today is better than having something perfect in three weeks time: thinker product-level, the knowledge you have of the product you work on allows you to make very profound and far-reaching long-lasting decisions.
Do not design systems around edge cases? Do not let the minority influence the majority of your product, always design solutions to edge cases as edge cases themselves. There’s no point weighing down the entire product to cater to a minority. Good example would be if five percent of your revenue comes from ie7 users do not spend twenty five percent of your time accommodating those users it doesn’t make any sense.
I don’t make decisions based on anecdotal evidence. Anecdotes are, by definition, edge cases. Their stories always trust data, don’t build it until you’ve been asked for it. It’s tempting to build cool things before anyone needs it, but that adds blur to the codebase. It could always go wrong. You might have to maintain that for the next two years solve every problem as and when you encounter it and finally expect under comedy change.
You know full well that clients make weird decisions. They will change their mind. The business can change, focus and direction every bit of CSS. You write every bit of code. You write should facilitate that. Never tie yourself now, never put yourself into a corner, and that is me saying. Thank you very much for listening.