Tag: software development

We write code to solve problems, to be executed by computers, but perhaps more importantly, to be understood by other humans.

Programming paradigms like imperative and declarative programming languages and data structures are abstractions of the real world that help us express the real world in code. We need abstractions because real world problems are difficult and complex, so we model them in programming code with abstractions that help us, humans, put into words (code) what it is that the computer needs to do to solve a problem.

Data structures are another abstraction that help us think about and work with data in the same way. They are a simplification, a categorization of data that helps us group and manipulate data in a way that helps us understand the data we need to be processed, but also to structure the data in way so it can be processed by our code.

Do you need to study and learn things like data structures to be a developer? Maybe not. But having a common set of problem solving tools makes it easier to approach specific types of problems and talk about how to solve these types of problems with other developers when we have a shared understanding and basic set of knowledge that we work with.

How you view the world around you is affected by your own prior experience. In software development, if you are just starting out, suggestions and guidance from more experienced developers can appear stubborn and shortsighted, but they’re offering a point of view based on their own experience too, what they’re seen work and not work.

For example, say you’re just starting out and you come across this new library/framework that has this one function that does exactly what you need, so you propose adding this new framework to the system.

A more experienced developer you are working with rejects your suggestion, saying that it’s not worth adding a new framework just to pick up this one function.

You go away thinking, ‘huh, that’s a shortsighted point of view, they should be more open to new ideas. They’re obviously stuck in their ways and resistant to change’.

Now think about this from the more experienced developer’s point of view:

• Adding another framework adds complexity to the system. More complexity means more risk, more things to go wrong, more things to maintain
• Relying on frameworks and modules brings it’s own overhead – you need to track security vulnerabilities and patches, and update your existing code to integrate with new releases if there are breaking changes
• Adding a new framework for the sake of taking advantage of one function brings additional risks, even in the parts of the framework you don’t intend to use. What if there’s a security vulnerability in the unused parts of the framework that could be exploited by a malicious user? What if something from the unused parts has an impact on your existing code, e.g. by changing module dependencies unexpectedly?
• What are the costs and risks to the project of adding this one framework? Would it be cheaper to build it yourself? Are the other costs and risks worth adding the new library even if in the short run it would be quicker to add it now?

If you’re just starting out maybe these are things you’ve never thought about before, or never been in a position where you’re responsible for making these decisions. When someone with more experience makes a decision or offers advice that appears unusual to you, ask yourself what factors they may be looking at the resulted in the decision. Ask them why they made the decision and/or what are the factors they were considering that led them to a decision? Often, things that appear to be being resistent to change and being inflexible are the result of considering and weighing many other risks and potential costs that you have not considered yourself.

If you learn how to use a saw and a hammer, that doesn’t mean you are able to build a house. Saws, hammers, screwdrivers – these are all tools. How you apply them to solve a problem (when and where) are techniques. There are multiple techniques you need to learn in order to understand how to build a house. While you still need to know how to use your tools, there’s fundamental concepts that you need to learn first, such as carpentry, masonry, and plumbing. Similarly, learning a programming language like JavaScript does not make you a programmer. You need to learn techniques for how to apply the tool to solve problems, not just learning the tool.

Tools can help you apply techniques and concepts, usually either in saving time or effort, or making a task easier than performing the task with your bare hands. Without a knowledge of these fundamental concepts you could certainly attempt to build a house (“I know what a house looks like so I know how to build one, right?”) and while you might end up with an end result that looks like a house, it will probably won’t be safe to live in. After the first winter storm you’ll probably find your roof leaks and you’ll be lucky if it’s still standing after being subject to strong winds.

Practice Makes Perfect

Knowledge of tools, concepts and techniques still does not mean you can apply them competently. Following with the house building analogy, if you read a book on house construction, could you successfully (and safely) build a house? Maybe. If you get your first job on a construction site and get some experience in house building and learn how to apply the techniques you’ve picked up from studying your house building book, it’s more likely for your next construction job you’ll be able to apply the knowledge and skills you’ve learned. Over time you’ll get advice, see what works and what doesn’t work, pick up tips and techniques that can save you time, growing your experience and competency.

Software development is no different. To improve your skills you need to get feedback on your work, you need to get advice on areas where you can improve, but just as importantly you need to practice your skills.

There’s commonly quoted advice that it takes 10,000 hours of practice to become and expert at anything. This has to be deliberate practice with the goal of improving your skills. For software development, spending 10,000 hours writing the same line of code over and over is not going to help you at all in becoming a better developer.

Don’t get caught up in comparing the pros and cons of different languages, or wanting to learn a specific language because you read it’s the ‘best’. Once you’ve learnt one you can more easily learn others. Spend time learning techniques and approaches to solve common problems. Learning a tool can be beneficial, but it’s not particularly useful if you don’t know how to apply it effectively.