Computer latency – What is the cost of latency

Usually, when we think about improving the performance of a program, our mind wonders towards the Big O notation. As good as that model may be, there are more aspects of performance that we have to consider. One of the important assumptions that we make when we use the Big O notation, is that all operations are created equal and take the same time to execute. I’m sorry to burst your bubble, but the operations we use are not the same. The time they take to execute varies widely, therefore, if you are aware of the different operation types, you can truly improve the performance of your code.

CPU’s have got faster

CPU MIPS over time — Millions of operations per second of different cpus thought the years

This is the evolution of the speed of the average CPU in Millions of operations per second. Source here. You may have seen it, or you may be familiar with Moore’s law. Getting back to the graph above, you might notice that CPU’s speed has been increasing steadily for a while now. Unfortunately however, programs need more than CPUs to run. They also need RAM, storage and most of times a network connection.

For example: While CPUs on average perform 12 times more operations per second in 2017 compared to 2007, the average internet speed for USA has increased merely 6 times (source here). The point I am trying to make here is that CPUs have gotten faster and the rest of the computer has a hard time keeping up.

Overview of computer latency

Here is an overview of the time it takes to do different types of tasks. To make things easier to understand I will turn those into dollars so you have a better understanding of the resources you are spending.

1 cpu cycle – 0.4 ns – $1 – a cup of coffee
Layer 1 cache – 0.9 ns – $2 – cheap menu at McDonald
Layer 2 cache – 2.8 ns – $7 – your average stapler
Layer 3 cache – 28 ns – $70 – Netflix subscription for 6 months
Reference main memory – 100ns – $250 – a cheap smartphone
Reading 1 MB from an SSD – 1 ms – $2 500 000 – a really nice house
Reading 1 MB from an HDD – 10 ms – $25 000 000 – a fortune 500 company s yearly profits
Send packet San Francisco to Hong Kong – 141 ms – $352 500 000 – a bit more than the GDP of Micronesia in 2017

Another point that might be worth mentioning here is that the further we get from the CPU, the higher the risk that something will go wrong. And so many things can go wrong with a computer programs.

What to do with this information

The purpose of all of this is to give you the broader picture when you design and/or implement your programs. Sometimes, mischievous traps are hidden behind the most benign database call. Be mindful where you spend your resources or you might find yourself running out of budget too soon.

Facebook

Twitter

How to deal with too many tasks efficiently

pile of files

Have you ever felt under pressure, like there is no end to the tasks, they keep piling up and you don’t seem to find the light ? Know you are not alone! I have made a new year resolution to become more efficient in my day-to-day tasks. Here is what I could gather so far.

There is always going to be work to do

The first thing I considered was to the workload, do less. I’m sorry to tell you, this will not happen. You are needed (and paid) to do a job, if you don’t have enough work to keep you occupied, then you are not needed as much as you think you are. Now, let’s get to some feasible solutions.

Have a plan

Do not underestimate the power of a well-thought-of plan. Trust me, it pays off in the end. When things are hard to do, then they should take time to plan. Think it through, don’t be afraid to take the time and build a schedule. Think about what you’re going to need, who does your work depend on? Are there any risks that need to be accounted for?

The Pareto principle

There is an observation called the Pareto principle, you probably heard of it, it’s the 80/20 rule. If you can’t be bothered to read the article, the most important take-away is that, on many occasions, 80% of the results come from 20% of the work. This sounds like a good place to start looking into improving performance. Check on your plan, see which of your tasks seem like they could impact your project the most? What are the tasks your customers really care about? And then focus on those. Your time is precious, you should spend it on what matters. If you have the option, a good idea is to delegate the less important tasks to someone else.

There is also a Peter‘s principle, but we’re not talking about that today.

Don’t multitask

You might think you are good at multitasking, statistically speaking you’re not. You might think you are, but you’re probably not. Try to reduce multitasking as much as possible, take one task at a time. Use your schedule to your advantage. Reserve blocks of time to focus on a single task. Now, the trick to this is to actually focus on the task and don’t get distracted. This means no facebook, no reddit, no emails, no instant messaging, and especially, no phone notifications. Unless something is burning (or really urgent) you stay focused on your task. An important note here is: don’t forget about breaks. You can’t stay focused for extended periods of time. Take a break, walk around, make a cup of tea (or coffee), relax for a bit before getting back to work.

Parkinson’s law

Time for another observation, Parkinson’s law says that work will expand to fill all allocated time. Parkinson’s law is timeboxing. To keep things short, in timeboxing, you put aside a block of time to focus on a particular task. When that block of time is finished, you take a break, unwind for a bit and reassess your progress. I have found that the following kinds of timeboxes work quite well:

Hard timeboxes: When the time is done, you are done with the task, whatever the state is. This works quite well for tasks that are detail focused. When you want to improve something to perfection, you could spend all the time in the world and you will not be satisfied. Apply a hard timebox around that kind of work, and whatever you end up with at the end of the time is good enough. Now, as always, common sense must prevail: If by the end of the timebox, you end up with something terrible, then you obviously have to spend more time on the task.
Soft timeboxes: When the time is done, take a break, reassess the task, think about what needs to be done and when the break is over, continue the task.

Another use for timeboxing, is grouping alike tasks together. You need to answer emails, do them all at once. You need to fill out paperwork, do it all at once. Code reviews, you guessed it, do them all at once.

One final thought: I found that using different lengths for timeboxes work really well. For me at least these are the timeboxes I use: 25 mins for answering emails, project planning and other management tasks, 40 mins for code reviews and 60 mins for actually writing code.

Do you have any other tips for a more efficient work schedule ?

Facebook

Twitter

Jack of all trades – a case for a general programmer

swiss army knife

What exactly is a jack of all trades ? According to vocabulary.com, a jack of all trades is a person who has some level of skill in many areas.

The world is changing, and so must we

Technology is changing faster than ever. If you look back even a few years, things seem almost unrecognizable. Just looking at graph of the most popular programming languages since 2014 should give you an idea on how fast things are moving. Just for reference: Javascript was invented in 1995.

Vertical vs horizontal learning

There are mostly two directions in which you can go as a software developer:

Vertically – getting more and more specialized at using a framework and/or programming language. You’ve gone further down the rabbit hole than most people.
Horizontally – you broaden your perspective, learn something new and add a new skill to your arsenal. You have a broad view across many fields.

Now, here is the catch: The more proficient you are with a language, the harder it is to improve. You don’t trust me?! Think of it this way: You learned more in your first week programming, than you did last week, right? Following this logic, it comes a point in your career when the effort to improve can be just too big. This is the time to look for something else to learn.

The framework is a tool

The language is a tool. It’s a neat little way you can express your ideas in a way the computer can understand them and then execute them. I sometimes see some developers who share an emotional connection with the language of their choosing. Usually it’s the one they’re most familiar with. Or it’s the one they started with. Keeping an open mind pays off. If you’re not a fortune-teller, you can’t tell what the future will bring. When you get married to a certain programming language, then it means you blind yourself to all the possibilities that lay out there, outside of your chosen horizon.

As the old saying goes, don’t keep all your eggs in one basket. It usually applies to valuable. I would argue that your knowledge is valuable. Don’t you agree ?!

Use the right tool for the job

As many other tools out there, different programming languages have different strengths and different weaknesses. Choosing the right tool for the job can mean the difference between breezing through a project, and spending lots of sleepless nights pushing a boulder up a mountain.

When you increase your bag available tricks, then you have a wider perspective on any problem you might try to solve. When it’s not that easy to think outside the box, it might be just as profitable to have many boxes you can think inside of. This seems like a good note to finish this article on, don’t you think ?

Facebook

Twitter

Scheduling – Come one step closer to full productivity

Productivity plan

The unicorn of office days: Having a productive day, each day, every day. It’s an admirable goal. It’s a goal we all strive to achieve. A step in that direction is having an efficient schedule. I’m here to help. Let get cracking!

Get the data

Step one in solving any problem is defining it. Try to keep a list of the tasks that need to be done within a given period. I usually find a week to work best. Use whatever you want to get a list of tasks. Forward warning, this might take some time and some trial and error to get used to. Some apps that I find useful when collecting tasks are:

Todoist – I use this to keep track of small tasks, repetitive tasks and reminders. I also use this as an idea bank to keep track of ideas before I get back to them and turn them into something more useful.
Trello – I use this to keep track of bigger projects. I find Trello boars offer a nice way to keep on top of multiple ongoing projects. If you’re anything like me, you have your work and then a couple of ongoing personal projects you need to deal with.

Disclaimer: There are the tools I’m using, and they seem to work fine for me. However, I must warn you, finding the right tool is a process. You will most likely need to try a couple of alternatives to find the one that works best for you.

A couple of alternatives might be: google tasks, google keep, your favorite calendar app.

Arrange the data

Do not underestimate the power of a well thought schedule. In computer science there is a concept called context switching. It’s the list of operations that the CPU needs to do to move from one task to another. They’re not processing the task, they’re the overhead needed to move from one task to another. Doing that to often can be a problem. You can spend more time switching between tasks than doing actual work. Our brains are not that different. To switch between tasks you need a long time. More so, you have to spend a lot of mental effort to do so. Why not try to minimize that?! Group similar tasks together! You have a bunch of meetings you need to schedule ? Bundle them all together, so they don’t interrupt your other work! Need to do some paperwork for the week? Do all the paperwork in one day. It will be a boring day probably, but once you get that out of the way, you can focus on your other tasks. More so, you have the bonus that you don’t have to think about paperwork.

Remember, it’s your schedule and it should be custom tailored to you. You know yourself best. I find that certain times of the day work best for certain types of task. For me, morning works best for intense, focused work, so I try to reserve big blocks of time to code early. In the afternoon, I don’t seem to have that much energy left, so I try to do my more mundane tasks: reports, meetings, planning etc. Try out different things to find out what works best for you!

Give yourself some wiggle room

Things happen. More often than not, those things cause delays in your schedule. This is normal. Unknowns cause delays. Keep this in mind when designing your schedule. Meetings run late. Tasks take longer than expected. So many things can go wrong. Part of the purpose of the schedule is to isolate those issues so that they don’t affect other tasks. Some takeaway here could be: don’t put meetings that can run late just before meetings that cannot start late. Find out what the important tasks are and deal with them early (so that you have a bit of time for the tasks to run late)

Tinker with the schedule

A schedule is not a one-time job. It’s living creature, it grows, it evolves. It’s aliveee! Every one in a while, review your schedule. Who knows, maybe there is something you can improve. Try out some different ways of scheduling, see which one works best for you. It’s your little world. You can do anything with it.

Do you have any more tips on how to build a nice schedule ?

Facebook

Twitter

What is computational complexity ?

Fractal - computational complexity

Complexity analysis leans on the more theoretical side of computer science. Ironically, I know, given this site’s motto, however, bear with me, it might just be worth it at the end.

Allow me to answer the first question you should have: What exactly is computational complexity ? I’m glad you asked! Computational complexity is one of the measuring sticks we’re using to compare different solutions, in an attempt to decide which one is the better choice.

What are we measuring ?

The goal for us is to decide which solution is better. That means, usually, how fast does the algorithm do its job. The problem with this approach, is that computational speed is influenced by both algorithm design and the hardware it’s run on. It wouldn’t be any fun to always decide that the best algorithm is the one that runs on the fastest computer, right ?! The good news is that a better algorithm will always run faster if the input is large enough. I classic fables terms: any slow turtle can beat the hare if they run on different tracks (In this analogy, the animal is the computer and the race track is the solution).

This sounds hard – How do we measure this?

Counting all the operations the algorithm makes is borderline impossible so instead we try to get a feel of how many operations we need to do for a given input. So you have to settle for an approximation, the upper bound of that approximation is the famous big O notation.

To get a simple form for of the big O notation you can do this: If you have of n elements as an input and your program does let’s say 45 * n + 55 operations, to get the big O value, you ignore the constants and keep only the biggest term involving n. So the big O notation for our algorithm would be O(n). This means that if you double the input, your program will run for about twice as long.

More so: When you add two solutions with big O notations (as in solve two problems one after the other in your program) the bigger one wins. That is O(n^2) + O(n) = O(n^2). If the alternatives are equal, you can pick either one. This is a quick and dirty way of getting to a solution, which tends to work in practice when dealing with algorithms. There are times when the bigger term is not obvious. You then have to go back to the basics and find a formula that serves as the upper bound for both therms.

Multiplication happens when you solve a different problem on every step of your algorithm. It works pretty much as expected, as in O(n) * O(n^2) = O(n^3).

If you want to read more about the subject, you can check out the Wikipedia article for big O notation

Time for some examples

Let’s take some examples and see what’s their computational complexity.

O(1)

The execution time remains the same, regardless of the input size.

Basic arithmetic operation (addition, subtraction etc)
Accessing elements in an array by index.
Searching for elements in a hash-map / dictionary object
Searching an object in a db using an indexed column

O(log(n))

If you can’t design anything that works in O(1), this is usually the next best thing. You can double the input for the run time to increase by one unit. Pretty sweet deal I’d say. Some common algorithms are:

Searching an element in a sorted list
Insert / delete operations on a binary tree / heap
Raise to the power (Exponential by squaring)
- Theoretically this is not O(log(n)) because the result size can grow linearly with the input size. However, I still think it’s a neat algorithm and worth mentioning. Furthermore, it behaves quite well in practice.

O(n)

The execution time grows with the input size. Doubling the input size doubles the execution time. Not a great deal, but it could work.

Search an element in an unordered list
Searching through a table using an indexed column.

O(n*log(n))

These are slightly more inefficient than O(n), although they offer pretty good performance.

Sorting – mostly sorting algorithms.

O(n^2)

The execution time grows squarely with the input size. Therefore, with double the input, the program takes four times as long to finish.

I’m adding to this bucket all the polynomial algorithms (O(n^x), regardless x). They are pretty similar so it’s not exactly cheating. Just go with it!

Generating pairs of elements
Inefficient sorting (bubble sort)
Joining tables

O(n!)

These are exploration algorithms. You get the input and you look at all possible solutions to see which ones work.

I’m also including here exponential time like O(2^n). The execution time grows so much that on an average computer you can usually handle an input size in the low tens (i.e. 30 / 40). Avoid using these if you can.

Backtracking
Traveling salesman problem

Disclaimer and other notations

The big O notation is a simple way to provide an upper bound on the growth rate of the execution time. In most cases that is enough, however, there are other notations that can be used if the situation demands it.

Ω – big omega – the execution time grows at least as fast as the notation. It’s a lower bound on the execution time.
Θ – big theta – the algorithm is bounded by both big O and big Omega. This can translate into: the execution time grows as fast as the notation.

We also have a little variant for all the notations, I’m not going to get into any details, but I just wanted to let you know.

Facebook

Twitter

Things to do when you’re not writing code

programmer at work

If you’re reading this, I assume most of your hours are spent staring at an IDE, coding away. What about the times when you’re not building shiny new features. If you’re lucky enough, then you’re going to have a couple of hours of free time every now and then. What should you use that time for ? So many possibilities. If you want to become a better programmer, then these few hours can be incredibly valuable. I’m here to help you get the most out of that time.

Tinker with your process

This assumes you have a process you follow through your day. If you don’t have a process, build one. A good starting point is the organization process It doesn’t have to be perfect. It’s not going to be perfect. That’s OK. A good process should be a checklist you go through for every piece of work.

What makes a process useful is that it can be improved. So start with something, anything. Now think about your process. Did you miss anything lately? Did you break anything? Does your work take longer than expected ? Did you find yourself waiting for others for extended periods of time? These are all questions you should ask yourself, and improve your process to prevent that! Sticking to a process is hard work, however, it’s worth it!

Read around

Reading is an important part of your work. You should not underestimate the value of information. The world of programming is in constant shift. New frameworks, patterns and technologies emerge every day. If you want to be a good programmer, you should keep yourself up to date with the latest trends. The best way to do that is to read around.

You should, at least, read about the frameworks you’re using. Become a guru on the frameworks you’re using. Look at the documentation. How is everyone else using that framework ? Is there anything you can learn from them ? Reading the source code can be incredibly valuable at times. Take your pick, but get to work!

Think about dependencies

What is the next thing you’re going to work on and why ? More than once, I have started on a ticket only to find out there are hidden dependencies required, assets that I needed (which take forever to track down and acquire). Think about the next piece of work and the following ones. Is there anything you should do now to save yourself some time in the future ? There are lots of little things that have the potential of costing you lots of time later down the road. The earlier you think about them, the easier your life is going to be. And who doesn’t like an easy life?!

Think about potential issues

The hallmark of a good programmer is the ability to think about the bigger picture, not just what you’re working on at the moment. How does what you’re working on now fit into the whole project? Is the work you’re doing now going to cause any integration issues. I’ll give you a spoiler: Most of the problems with software can be found at the joints. What external services does your ticket (and project for that matter) depend on ? What happens if that service is down, or slow, or wrong or any of the myriad of possible ways of things to go wrong with a service. Catch them early and not only you’ll save yourself a headache (and possibly an embarrassment when the project goes live) and you will prove yourself as an awesome programmer. Two birds with one stone.

In conclusion, if you find yourself with some time on your hands, don’t waste it, use that time to improve yourself, like a knight sharpening its sword before a battle (I always wanted to say that!). Thse thins are valuable in the long run. Instead of stealing some moments whenever you have them, try to make them. Take a break from writing code and improve yourself. You’re going to be better at it! Your project is going to benefit! Everybody wins!

What do you usually do when you have a bit of free time on your hands ?

L.E. As with everything in life, common sense should prevail. This does not mean you should drop important work when important work needs to be done, nor does it mean you should completely abandon your other hobbies and focus on programming 24/7. If you need a break from work, you should take a break!

Facebook

Twitter

How to step up your automated tests game

fixing unit tests

This is a follow-up of my previous post here. If you’ve ever had to write automated tests, you might have some bad memories lingering around. Automated tests have a way of becoming troublesome as time goes by. You end up spending more time fixing the tests than adding actual features. When that happens, you don’t care about test anymore, you don’t run them, you’re not worried when they fail and you just don’t add new ones. That leads to brittle code and things break really bad really fast. I’m here to tell you there is a way to keep automated tests manageable.

Simple is better

Simple tests are the better tests. They should be simple to read, simple to run and simple to add. Clean up the setup. Wrap complicated setup in nicely named functions. Keep the logic linear. You should never have an if in your tests and you should scarcely use for loops or other exotic structures and/or logic. It’s as simple as this. When you write simple tests, you get easy to maintain tests.

Be precise

It should be clear what you are testing. A very good tip I have for you on this is to use the given/when/then format. What is that, you ask?! It’s a way of explicitly splitting your tests into three distinct sections.

Given should deal with setting up the data. Everything your test needs to run smoothly. This includes, but is not limited to: seeding the database, adding any mocks required, pre-generating any data and constructing all the models that you will use later.

When is where the magic happens. You test whatever you need to test here. You should make sure it’s obvious what you are testing. If you feel you’re not being clear enough, then wrap the call in function and name it accordingly.

Then is where you check your data. You have to make sure your test did what you want after all. The checks should be clear and self-explanatory. Additionally, the checks should be the direct effects of the when section. Don’t do unrelated assertions, even if they are true, unless you like to fix unrelated tests for every change.

I prefer using comments prepending each of the sections to make the tests even more explicit.

Test one thing at a time

Try to keep your test scope as narrow as possible. There is a two-fold benefit to this approach. First you get a clean list of failing tests when you break something. Hopefully you have named them well enough to diagnose the issue with just that. Secondly, updating the tests to match the code after you make a change should be a lot easier.

As I have hinted, naming is important here. The test name should hint at the non-trivial setup required and contain the assertion being made. A big red flag is if you find yourself having to use and in the test name. Some examples of some good test names are:

if the user is unauthenticated the server should return unauthorized

if the user is unauthenticated the server should log the request

A bad test name would be:

if the user is unauthenticated the server should return unauthorized and log the request

You’re actually trying to test two behaviors here.

Can you think of any other useful advice that could help us all with our tests.

Facebook

Twitter

Testable code design patterns

As you might have realized by now if you follow this little blog (and you should), I’m a huge fan of automated tests. If you’re not, I assume it’s because you either don’t find them useful, or you find them hard to add.

Tests are useful because code breaks. My code, his code, everyone’s code breaks eventually (and that includes yours too). What you aim achieve with automated tests is to break your code before you deploy it. It’s much easier to think of a fix when you don’t have people running around with their hair on fire because the site is down. Also, it doesn’t do you any good as a programmer to write code that breaks as soon as they leave your door.

Now that we decided tests are useful, let’s see what we can to make them easier to add.

Write testable code

You should see testing as an integral part of development. In the same way a programming language and/or framework impose some patterns in your code, in the same way the decision that you’re adding tests should change your code. I’m here to tell you there is a way to make your life a lot easier. There are a lot of design patterns out there. Together we are going to riff through a few that should make testing your code a piece of cake.

If your code is easy to test, you will test it more. With this you can ensure a more resilient project in the harsh production environment.

Dependency inversion.

You have more details here. It sounds a bit fancy at first. It’s not. The idea is this: Whenever a function/class depends on another module, they should get that module as a parameter and not instantiate it themselves. Combine that with automatic dependency injection and you’re in business. Mocking and stubbing will never be an issue again. You can completely isolate modules and mock out their dependencies. From then on the sky’s the limit on what you can test.

State is evil when testing

This is not so much a design pattern, as it is advice. Nothing will make your head hurt more than handling global state in tests. Then why don’t you save yourself the trouble and keep the state to a minimum. As a rule of thumb, all functions should be stateless. If called with the same params, then they should always return the same result.

If you remove state from modules, the problem becomes how do you deal with modules that inherently should have a state, things like db connections and network connection. My approach on this is to isolate the state in a shared model. Then pass that model around anywhere it is needed.

Be in the right mindset

Accept the fact that you’re going to have to test whatever you are working on now. Always keep that in mind when writing the code. Thinking How in the world will I test this, is a good way to spot anti patterns and code smells early on.

You have to think about module dependencies and if you should another. Then where should the logic and state live. Every now and then, you get to a point where you need to do some hackish workaround because the testing framework just hates you. That is OK, it’s just like every other workaround you had to do to get past a framework limitations.

These may not all be design patterns. However, I do feel that the advice above covers the gist of what you need to do so that automated tests don’t become a burden. See you next time with some advice on how to write better tests for your code.

Facebook

Twitter

Soft skills do matter

Let’s start at the beginning: what exactly are soft skills ? Soft-skills, is an umbrella term, covering the less technical skills you need for your work. Stuff like communication, time-management, delegating and other fun stuff you have to do outside of an IDE. I sure hope you are one of those programmers that do consider these skills important. Whatever your beliefs are, stay with me and you might just learn something.

You work with people

Obviously, but think for a second of the implications. Your work is based on other people’s work. People decide your tasks. People evaluate your work. And, ultimately, people pay you for your work. When you think about it this way, it seems important now, to learn how to deal with people. This includes negotiating, giving and asking for feedback. Some of the most efficient programmers I know, are great at working with people. They know what the client actually means when they ask for something. They know how people react when they are given both good and bad news. I would argue that a big chunk of their professional success has to do with their people skills. I’m not saying that you can’t be a good code without people skills, I’m saying that improving your soft skills make you a better programmer.

Prioritize

You are a professional and you should treat yourself as one. You should work on the most valuable piece or work first, and then the next one and the next one and so on. Now, the most valuable task might not be the most fun to do, nor the most challenging. It’s not the work you want, but it is the work you need to do now. Do that! It’s that simple. If you put the project above everything else and you treat your time as a valuable resource (which it definitely is), then, what you should be doing now becomes obvious. Do whatever needs to be done to move the project forward by the biggest margin. Additionally, your time is a valuable resource. Don’t waste it on useless tasks, don’t slack off, and never ever half-ass the work.

Opinions do matter

Imagine this: Someone asks one of your colleagues to recommend an awesome programmer for this cool project they have going on at the moment. Will they pick you? Would you like them to pick you? Be aware of your colleagues opinion on you. There are two easy steps to get there: ask and then listen! Learn what your peers want, what they value and fine tune your discourse to emphasize what they value in your work. Now, this might sound a bit mischievous. My advice here is: be honest. There is no harm in glossing over the details someone does not care about, in order to focus on the details they do care about, but don’t lie to your peers.

Communication is important

If you stop and think about it. During your average workday, you have a lot of discussing to do. Some are not that important, like the ones about the weather, while other matter a lot more, like the ones about your promotion. You spend so much time communicating, why don’t you try to do it right ? Communications are the result that the sum of all your soft-skills produce. You should start by listening to your manager and try to understand their motivation. Then, you should make sure you work on the most valuable piece of work available. Trust me that will make your manager really happy. Then, think about the way you are presenting your work. Does your manager understand that your task is difficult, does your manager understand that you care about the same things he cares about ?

I know this sounds tedious, trust me. However, the good news is this: these are all skills, and even soft skills can be learned and, when practiced, improved upon.

Facebook

Twitter

Greenfield project – how to get it right from the get-go

You lucky programmer you. You get to work on a new project. A shiny new toy for you. All the possibilities that lay ahead. Simply limitless! Now the only question is: how do we do this right? How do we make sure our little project does not end up a big ol’ mess that is impossible to handle.

Decide on the spec

Before you can get your hands dirty, you have to have a plan. Right? You should have a very, very good idea what you have to do. Here are a couple of questions that you should have the answer to before you start any work:

What are you trying to solve with the project ?
What is the workflow of the project ?
What is the expected load (now and in the future)
What is the most important feature ? If you have to settle for three features, what would they be ?
Are there any risks you need to look out for ?

Start reading

Now that you know what you’re doing, start reading! Honestly, there is a lot of reading involved before starting a new project. You should know what the available frameworks are, what are their limitations, what are they good/bad at. Additionally, you should have a good idea what add-ons you should use for what tasks and how well documented they are. Another important thing you should look into if known issues. There is a lot of less-than-stellar code out there, you should make sure you’re not relying on one for your awesome project. So, start reading now and don’t stop until you know everything. Well, maybe not everything, but you have a good idea what adding a particular framework means. Little word of advice here, if I may, just because you have experience with something, it does not make it the right tool for the job. Don’t skip over this stage.

Decide on the tech stack

Decisions, decisions! There are a lot of choices out there. Some are more mature (like Spring), while others are quickly changing offering new shiny toys at every turn (like React). You need to make a decision now that will affect the project it’s whole life. No pressure, right ? This is also the stage where you decide the infrastructure: what database will you use ? Will it be hosted on your server, or somewhere in the cloud ? What OS will the server be running on ? How will you do the deployment ? All of these are important questions, so take your time thinking about them now. You’ll thank yourself later. This is also the stage where you are in a safe position to make promises about timelines for your project, set deadlines, milestones, you know, all those things.

Set some ground rules

The beginning an important time for your project! The rules and conventions you set here are going to stick around for a long, long time. Be careful what patterns you add to your project here, they can save you or hurt you easily later down the line. Read about your tech stack’s best practices and make them part of your project. It’s going to be a lot of chaos in the early days of the project. You should be vigilant, so that you spot the changes that go against your rules and correct them.

Good job bearing with me this far. Now it’s time to go out there and make your dream project happen! Cheers!

Facebook

Twitter

CPU’s have got faster

Overview of computer latency

What to do with this information

There is always going to be work to do

Have a plan

The Pareto principle

Don’t multitask

Parkinson’s law

The world is changing, and so must we

Vertical vs horizontal learning

The framework is a tool

Use the right tool for the job

Get the data

Arrange the data

Give yourself some wiggle room

What are we measuring ?

This sounds hard – How do we measure this?

Time for some examples

O(1)

O(log(n))

O(n)

O(n*log(n))

O(n^2)

O(n!)

Disclaimer and other notations

Tinker with your process

Read around

Think about dependencies

Think about potential issues

Simple is better

Be precise

Test one thing at a time

Write testable code

Dependency inversion.

State is evil when testing

Be in the right mindset

Prioritize

Opinions do matter

Communication is important

Decide on the spec

Start reading

Decide on the tech stack

Set some ground rules

Recent Posts

Let’s stay in touch

Categories

I’m not a robot

Archives