Before even writing code, what do you need to know?
You will be ecstatic to know that writing code is actually the easiest part of software development, and that is mostly the case if you get the preceding processes right, and in the right order.
On the flip-side, writing code can be a nightmare and is often perceived as hard just mainly because the due processes were not followed in coming up with solution code.
Before you even write a single line of code, firstly you need to LISTEN carefully to the requirements and understand them. Secondly, you need to ANALYZE the requirements for possible solutions, then from what you see as the best possible solution, DESIGN how you are going to implement your solution, then and only then you can CODE your solution effectively.?
The initial pipeline of skills that are required for you to produce great code solutions and or programs are Listening Skills, Analytical Skills, Designing Skills, and Coding skills, in that order.
The saying that ‘if you plan it with a pencil you can weld it with steel’ becomes especially true in this instance. PLAN first. Even when you are in an interview, do not rush to give a solution. Go through a planning session first, at least in your head first.
When you become a fully matured software developer, you will be expected to have developed all these sets of skills which are quite vital if you are to build the right solution and build the solution rightly.
It might be a relief to many who are just starting that you don’t necessarily have to be a master at all these skills, at least initially in the early days of your career, because when you work at an organization with mature processes, some of those skills and roles are filled by different members of the software engineering?teams.
You may be lucky to have project managers, solution architects, systems analysts, and business analysts, for example, all complimenting your efforts as a software developer.
But just the fact that someone else is carrying out those roles for you doesn’t mean that you need to be complacent; it will help you to have all those skill sets. At least the basics.
In smaller projects, and/or smaller teams, you will have to fill in those shoes yourself.
It will help you as a developer to pay attention to these kinds of skills, as the lack of them is what tempts many to simply use ready-made solutions that litter the internet today in solving problems that are in a totally different domains, and environments altogether. Of course, there’s an element of reuse that we always have to be aware of and utilize in certain circumstances. But we overdo re-use, without even thinking.
This behavior is lazy and is one of the factors that stop us from moving forward technologically in sub-Saharan Africa.
We are littered with software solutions that were primarily built for the USA?and Europe and are hardly as effective in our environment.
That’s a topic for another article or at least a white paper, and we leave it for another day, but still, as an example compare with China and the East: they build their own solutions that speak to their own problems and culture.
That said, after going through these tutorial series, you will be in a better position to build solutions from scratch, and it will become easier for you to do so. So let’s dig into the skills.
Listening skills
Whether you are working directly with an external client or you have internal product owners within your workplace as your internal customers, the first thing that you will be required to do is to LISTEN.
Never miss this first step of paying attention to the need at hand. Even if you are developing an application for yourself, you need to listen to the need at hand.
I'll post an article in the future on how to get a software development?job, where I'll also deal with aspects of going through a successful programming interview?and if you miss any part of the problem definition?from a technical interviewer, and didn’t clarify, you surely will not enjoy the whole process of providing a solution, whether in an interview as in this instance or in a real-life situation at the workplace.
Take notes if you are having a conversation with an internal or external client. Most workplaces you will be a programmer in will have project management tools like Azure DevOps, Jira, etc where the problem you are about to solve is documented. But this is often inadequate.
A product owner will most probably just provide a skeleton problem definition?on a story, and not necessarily a whole essay on a problem.
You are expected to understand the problem.
Here’s the fun part: in many colleges and universities, you only require a 50% mark to pass your exams, while in Microsoft’s certification exams you need at least 70% for you to pass, but in the workplace you will actually need to get 100% of the requirements delivered right!
I actually find that fun and quite satisfying when I have gone through all the processes and then my client is happy with my solution.
That right there is one reason to choose a career in software development. It’s so satisfying!
Believe me, you will be motivated more and more when you get a series of tasks right. Progress is the biggest motivator in any case.
An object in motion stays in motion, with the same speed, and in the same direction, unless acted upon by an unbalanced force”? - Newton's first law
Never make the mistake of procrastinating in asking questions when you do not understand the problem. Always ask immediately, and no sane subject matter expert will take you to the task of asking a lot of questions. In fact, it is a plus for many.
Many make the mistake of saying I will understand this when I’m actually coding for the problem. And I’m guilty too, I have made that mistake quite often, especially in my early coding days when I didn’t have that much confidence, and more often than not, it doesn’t reflect too well on you as a developer when you misunderstand requirements and leave it as such until you can’t?afford not to understand anymore, i.e. when it’s time to do and deliver the solution, no matter what.
It will be an impediment to climbing your career ladder if you do not ask questions immediately.
Certainly, it does play a part in slowing down production for the whole team if you do not ask the right questions at the right time.
There will be times in the workplace, especially if you’re new to a domain when most of the requirements won’t make sense at the first go.
In the course of my career as a software developer, I have worked with people who actually request to do a recording when the requirements are being given, and/or explained even in a one-on-one meeting, and I have seen it work for them. Whatever it takes for you to be helped to understand requirements, do it at this stage.
Now that you have listened as much as possible and you have taken as many notes as possible, whether mental notes, on paper,?on your computer, whether organized by a project management tool or not, what is your next skill set that you need to have?:
Being able to analyze the problem at hand will come in handy, so let’s look at analytical skills in the next section.?
Analytical skills
Be assured that analytical skills are nothing more than interpretive skills. You will be required to have an aptitude to interpret, at least into forms you can understand, whatever you’ve been given as a problem definition.
After you have understood the problem as explained in the previous article, do you then go and write code? No, not just yet. You need to analyze the problem and think of possible solutions.
Let’s look at an oversimplified example:
Suppose you have a problem that you need to move from Town A to Town B for a meeting. Let’s take this as our problem definition. How to move from Town A to Town B.
Your desired end result is reaching Town B. But how do you get there? You think of several options as follows:?
An impatient and bad software developer/programmer will not even consider any other options, just because he drives to work every day, the first thing he would think of is his car, and that he would drive there.
But is driving there the best option available?
It will depend on several ‘environment’ considerations. Is there a deadline for what time he/she needs to arrive in Town B by?
Would the traveling have to be done in peak hours, where he might risk being late because of traffic jams?
Perhaps cycling would actually get him/her there faster. But would he/she want to arrive there sweaty for the meeting?
Perhaps he/she may use a motorbike. But maybe he/she needed to carry some heavy luggage to display at the meeting?
So maybe taking a train would be the best option. But there’s still a distance from his/her home to the train station.
So finally he/she decides to use his/her car to the train station, find parking, and then proceed with the train.
That would be the final solution that he/she would use.
There are other solutions, like walking to town B, and while it is a possible solution, he/she might rule it out at first thought, just considering that he has to carry some baggage for a distance.
Or taking a helicopter, which would be too expensive, or indeed taking an airplane, which would be overkill and impractical for such a small problem.
Notice that he/she has already gone through the possible solutions and has already formed a mental note on what solution will work best under the circumstances.
A great programmer will not rush into coding when presented with a problem.
There will be options that he will rule out immediately, like walking to town B in the above example.
I will talk about interviews in a later article, but for now, it will help you to know that you’d score a lot of points in a programming interview, if you are able to show that you can?analyze a problem and propose options in how you will solve it, giving pros and cons, and finally coming up with a choice and why you came up with that choice.
?Some technical interviewers will place more priority on this rather than the actual code.
I cannot stress enough that you will always need to formulate a full picture of a solution already in your mind, even for simple problems, before you attempt to write a single line of code.
You can either formulate it in your mind, or you can use several design tools to bring it into a bit life.
I will expound on some of those tools in the section where we deal with solution designing skills?later in this same article.
For more complex problems, you may not just be able to formulate a solution in your mind, and there are different approaches that you can use to get to the solution. It will always help a LOT to know data structures?first, which will help you in coming up with efficient solutions.
Data structures?span across different programming languages and can be agnostic to programming languages or programming paradigms.
I will expound on programming languages?and programming paradigms?in more detail, in one of the later articles.
Whenever you mention Data structures, there will always be a need to mention commonly known algorithms that have been used by the software engineering?fraternity over the decades to provide effective solutions.?
We can do an entire book, just on problem-solving, where we can explain in simple terms an otherwise complex topic ‘Algorithms and Data Structures ’, and frankly, that topic deserves its own book, but for now, it will suffice to just know the techniques for solving complex problems available to you, that have been proven over time and are used over and over again by the software engineering?community.
?Some of the most known and used techniques are as follows:
Don’t feel overwhelmed, especially with just the words. Remember, one of the main aims of this article series is to guide you to become a fully baked software developer in the end. You need to know these things, but only at the right time. For beginners, this is not the time. Just having an awareness they exist and how they fit into the software development?picture is perfectly fine for now.
For the purposes of this article, it will suffice to just know that the software engineering?field as a discipline has been growing, and in its growth, there is what is called a communal body of knowledge that has been standardized and accepted as common wisdom and standard approaches to solve problems, some of them are the ones we are discussing here and below.
These techniques in solving problems have been used over the years and are always being refined over and over. It will help you as a developer to learn and use what others have found useful before, in trying to solve common problems.
Let’s briefly explain some of the techniques:
Brute force technique
We have actually already seen a brute force approach to solving a problem right here in this same article, earlier on.
We didn’t just give it a name when we were explaining the scenario. Never be scared of words that seem to be too technical. Let’s recap the problem we presented when we wanted to find the best way to travel to a meeting from Town A to Town B.
Our approach was to enumerate all the possible scenarios, and from them then determined the most practical way to travel from point A to B.
That’s not exactly efficient, is it?
Let’s try to think of a scenario where we are tasked to come up with a software program that plays a bao board game with a human opponent.
With a brute force approach, every move made by the human opponent would consecutively have to be met with an analysis of every possible move from every hole in every direction, and what the resulting state of the counters/seeds will give next as an opportunity to the other player, what next the computer bao player will have to do, and vice versa, until the winning state.
This would take a lot of computer processing power, and even with today’s fast server processors, it would result in a visibly slow responding computer program.
Even though there’s a surety that if all calculations are made, a winning formula will be found, surely there are more efficient ways of coming up with a winning formula or algorithm.
These are some of the kinds of things an experienced programmer would consider.
A junior or not-so-experienced software developer will go for the solution that works in an instance without considering other variables.
But don’t worry, that’s why this article series is there to introduce you to habits that will make you a great and authentic software developer.
Let’s look at other approaches to solving problems.
Divide and conquer technique
You are probably no stranger to this term in normal language terms. It's a concept that has been used and applied extensively, for example in politics, and I won’t elaborate there, politics being a tricky subject, I’ll leave your mind to explore your imagination.
And you’ve probably seen animal predators like lions and tigers on National Geographic?documentaries, where they know how hard it is to get their prey in a large group versus dividing their targets into smaller and smaller groups, preferably eventually just having an individual to contend with.
领英推荐
It is way much easier to conquer an individual. If they do, they have divided and conquered. Again you’ll see that if someone says ‘use the divide and conquer algorithm’, it sounds a bit more sophisticated and complicated than it is in real life. So, never be scared of any so-called big words. Behind the words are some simple concepts. It will do you well to just understand the concepts using parallel and natural situations first. In that way, you will never forget what a technical word means.
?More appropriately for the purposes of this article, in computing terms, the divide-and-conquer technique solves a problem by:
Once again with this article series just being a technical career guide in software development, it is sufficient to just be aware of the existence of commonly approved and adopted techniques by the software development?body of knowledge.
There are other common techniques like Iterative refinement?technique, Graph modeling?technique, Reduction?technique, Dynamic programming?technique, and more, but for the sake of not confusing a newcomer into the software development?field, I have reserved a detailed technical discussion on algorithms and data structures?in a separate article, as this is such a huge and important building block for a stellar software development career, it requires its own separate and comprehensive coverage.?
Solution designing skills
In your normal day-to-day lives, you have seen ordinary buildings or houses and you have probably also seen architectural buildings. You will tell from afar the difference between a house designed by an architect and a normal house that somebody just decided to start building without a proper plan.
That is the same case with software solutions that have no architectural designs at all, which just evolve along the way when building the solution. The same structural failures that you have heard of in badly architected bridges and buildings have the potential of happening with a software application if it was not architected properly.
For an average software developer, you will most likely be writing your code with the help of some sort of framework, e.g. .Net for Microsoft, and these kinds of frameworks and libraries as will be discussed in one of my later articles, are usually architected by experts already and offer some sort of layer of protection from bad code, so you could be assured that nothing will go terribly wrong.
But still, you will have a responsibility as a developer, not to just write code all over the place, and anyhow, as a best practice. You don’t just write code and use it as long as it compiles and runs. There are methodical ways that have been proven over the years,?and even without following commonly accepted norms, you as a developer are expected to use your brain and creativity to design code that will stand the test of time, and users. That’s why software development?is fun, isn’t it?
Now for very experienced developers, who have made all the mistakes they could have made over time, and learned from them, you tend to develop a knack or instinct that tells you from the top of your head whether you’re going the wrong way with a solution.
If you reach these stages, you may be tempted not to ‘waste time designing a solution, and putting things on paper, after all, you can picture everything in your mind, but I’d recommend any developer to have some sort of blueprint?from where they’re basing their solution on.
It makes everything so much easier, when you are referencing the designs, and helps you plan and stay on course with the solution. Potential structural flaws can also be detected in the early stages when you put the designs on paper.
In the course of your career as a software developer, you may happen to work for companies that are quite religious about having every solution go through designated Business Analysts and Solution Architects first, and only after they have done the designs, do they allow Software Developers to then come up with functional requirements specifications?first, then and only then, to go ahead with providing a code solution.
You’ll find this common in very large enterprises, and while it may seem like a waste of time to many, it helps quite a lot over a period of time if you have to come back and revisit a solution that was done years ago.
You will need to have a basic understanding of object-oriented programming(oop) before we expound on some Unified Modelling Skills, so let me introduce oop first
?Object-Oriented Programming Introduction
I will expound on Object-Oriented Programming?in a bit more detail when we look at different programming paradigms?in one of the later articles, but for the purposes of solution designing skills, we need to at least have an idea of what object-oriented programming?is. As it is currently the most common paradigm that most software developers?are working with at the moment, and will most likely be the one you’ll use in the future if you are a beginner.
Object-oriented programming is a method of programming that looks at the world and its entities as objects.
Each object becomes alive as an object when a program is compiled and running and interacts with other objects as part of a software application solution.
For example, if you design a software application that deals with monitoring employee attendance, an employee called Kenneth would be an object within the system, the moment he checks into the office premises with his card, for the first time after signing the acceptance letter, he remains an object as long as he is alive in the system and interacting with other objects.
His projects assigned to him are also objects within the system, even though a project is not a tangible thing.
An object is simply a thing, whether physical or virtual.
But before an object becomes alive, there is a class?that it originates from.
Before Kenneth becomes an object there is a class?Employee that he first had to be employed (or originate) from.
Class 'Employee' can create different objects. We could have Sally as well coming from the class?Employee.
Yes, Sally and Kenneth's objects may all come from the Employee class, but they have different attributes?that we may identify them with.
The attributes?include Name, Gender, and Department.
Employee class?has properties. These properties include Name, Gender, and Department.
You can get or set the properties of the class?from the attributes?of an object.
A class?is a blueprint?for an object.
Class 'Employee', may also have methods?like an 'ApplyForLeave' method.
A typical class?has attributes?and methods.
Unified Modeling Skills
Basic unified modeling language?(UML) design skills will be quite important for you as a software developer. Least if you cannot design the UML diagrams yourself, some workplaces are lucky to have dedicated software architects who may do the designs for you, but you should aim to be able to read the basics.
There are 2 types of UML?diagrams, namely: Structural and Behavioral diagrams
I’d suggest you at least familiarize yourself with the following structural and behavioral diagrams?as described below.
There are more types of structural as well as behavioral diagrams, but these are the most commonly used ones:
Class diagram
Here’s a simplistic class?diagram depicting the objects called Publication, Book, and Magazine, their properties, some methods, and relationships between the objects:
Cardinality in relationships
The relationship between one object and another, or relationships between several objects, is what is called cardinality. In the example figure below, you’ll see that one company may have many employees, and actually has to have at least one employee, hence you’ll see the mandatory(or required) symbol depicted in the ‘one to many ’ relationship symbols between the company and the employee objects. In real life at any company, there will be many employees. And each of those employees may work on many projects.
Therefore in a normal company, we can have many employees that can work on many projects. In the same example below, you can see a many-to-many relationship between the employee object and the project object.
?Relationships
There are six main relationship types between objects that you will have to understand as a software developer, and that is across programming languages, at least in object-oriented programming.
I am assuming that you will be learning your programming with a language based on the object-oriented paradigm, which is the most commonly used.
If you want to know what other different programming paradigms?are available,?I'll post an article later that expounds on programming paradigms, please follow me to get notifications when I post about the paradigms.
Let’s briefly describe each of the relationship types below:
An association?is simply a relationship between classes. In UML?it is depicted as an arrow, as shown in the figure below. In the figure above, you’ll see how the arrow that depicts an association is utilized in a simplistic class?diagram.
A 'RentalAgent' is not a Building,but has some ‘association’ with the Building,when he/she prints invoices for the Building. That’s why we connected the RentalAgent class?to the building class.
In the example above, you will see an inheritance?arrow connecting the House class?to the Building class. This is because a House IS a Building.
The keyword for inheritance?is the word: ‘is’.
The 'RentalAgent' ‘IS NOT’ a Building, and therefore cannot inherit from the Building class.
A House is a Building,and therefore can inherit from a Building.
All properties and methods?in a super-class?called Building,can be used in the sub-class House. You can, and with emphasis on ‘can’ ‘DetermineRental’ for a house by inheritance, without explicitly defining it in the house class.
Realization?is a relationship between two classes in a UML?diagram where one class?specifies behavior and the other class implements or executes the behavior. In other words, realize the behavior.
There is a source class, called the realization class, and a target class, called the specification class, and the relationship is also often referred to as being between a supplier and client.
In many cases, the specification class?will be an interface, or a collection of operations, with the realization class as the implementation of those behaviors or operations.
Dependencies?in UML?indicate that a source element, also called the client, and a target element, also called the supplier, are related so that the source element makes use of, or depends upon, the target element. Changes in the behavior or structure of the target may mean changes in the source.
This type of association?relationship indicates an element is formed by a collection of other elements. For instance, a company has departments or a library has books. The aggregate element relies on other elements as parts, but those other elements can also exist independently of it. Aggregation?is represented by a line from one class?to another, with an unfilled diamond shape near the aggregate, or the element that represents the class that is assembled by combining the part elements.
Composition?is not a standard UML?relationship, but it is still used in various applications.
Composite aggregation?is a subtype of aggregation relation with the following characteristics:
Composite aggregation?is described as a binary association?decorated with a filled black diamond at the aggregate (whole) end, as shown in the picture below.
There are other types of structural diagrams?like Component Diagrams, Object Diagrams, and Package Diagrams, that you might want to do a search and have a look at, especially if you want to specialize in solution designing, but the most common structural diagram?is the Class Diagram?that we have just briefly described.
Understanding how to interpret or draw class?diagrams will usually suffice for the purposes of a software developer, therefore we won’t go into detail with the rest of the structural diagrams?in this article series.
Behavioral Diagrams
There are several types of behavioral diagrams, including Use Case Diagrams, StateMachine Diagrams, and Sequence Diagrams, but since this article series is just a guide for software developers, we will look at one type of behavioral diagram that is commonly used by developers, that is the Activity Diagram:
With this activity diagram, you can see a hypothetical process for a customer walking into a shop, and wanting to purchase a fridge. The activity diagram takes you through different swimlanes (Customer, Supplier Shop, Third Party, and Bank), where all the step-by-step processes are recorded.
There are several tools you can use to come up with an activity diagram like this, also referred to as a flowchart, and I’d recommend using something as simple as Microsoft?Visio?from your desktop.
The basic flowchart?shapes that you need to be aware of, at least to be able to interpret an activity diagram easily are shown in the following diagram:
Summary
This article is about the skills you will need to make sure that you have before writing any code. And we looked at several of them, including the need to have listening skills, analytical skills, solution designing skills, and unified modeling language?skills.
For analytical skills, we briefly went through a few techniques that we may use in analysis, and we talked about the brute force technique, and the divide and conquer technique.
I briefly introduced object-oriented programming concepts, and at the end, I talked about a few basics in unified modeling language, with structural and behavioral diagrams.
This introduction to skills needed before writing code sets us up nicely to look at the skills needed to finally write code. I’ll discuss these skills in the next article.