The importance of math and mathematical intelligence in software developement careers

[Andy Jack]

I suspect that if "you" don't have an aptitude for math, then software development (SD) is NOT for you. But, I don't really know how much math related thinking most SD jobs require.
Unless you are into algorithms, artificial intelligence and such, I guess you will probably not see more than a couple of simple formulas.

1 - Are there any ways to assess the mathematical aptitude (MA) of a person properly ?
2 - How much math do most developers use in their career and how complex is it ?
3 - What are the topics in math that you must know well for a career in SD ?
4 - Which SD careers use/need the least math ? (Front end developer job like JavaScript, HTML, CSS ??? Those would probably need more of artistic intelligence and common sense)

[chris webster]

There's a nice personal take on this question by one software developer here. I'm strongly inclined to agree with him.

I got into software development at a time when there was a shortage of computer science graduates, so you could get a trainee job without a CS degree by doing well in an aptitude test and the usual recruitment procedures. I had a year of CS at university, and roughly university-entrance level maths, but I learned most of my skills on the job, through working/experimenting/reading/studying etc. It worked out pretty well for me, at least until I fell off the employment ladder recently, but that was mainly due to not keeping my skills up to date in line with the job market rather than any lack of maths (or CS). Certainly I never had any problems keeping up with (or even out-performing) the CS graduates among my colleagues who typically had a stronger/more recent maths background (and here's another take on whether CS is entirely useful for software engineers).

But I think the guy in the first link above is right: you probably do not need maths for most areas of everyday development (although domains such as cryptography, image processing or high-end financial systems will certainly require maths), but having access to those skills may make a real difference when you want to look at more interesting stuff. In my case, I've been prompted to start refreshing my maths skills by a growing interest in functional programming and in "Big Data" and machine learning. But it's a heck of a long time since I did any maths, so it's a bit of an uphill struggle right now.

But like I said on one of your other threads, Andy, you probably need to start learning something - anything - thoroughly right now, rather than constantly searching for the Platonic Ideal Skillset to ensure permanent employability in a hugely varied industry that is constantly changing anyway. Get good at a few things, then see what else looks interesting/useful as you develop your own skills/interests/goals. The main thing is to keep learning.

Good luck.

[fred rosenberger]

I only skimmed the first article Chris linked to, but I have to strongly DISagree - with a caveat.

I think math is critically important for all developers...however, I think math is a much broader topic that most. From my experience, most people think of math as calculating results, or applying the correct sequence of theorems to prove a hypotheses.

But to me, math is about logical thinking. It's about analyzing a problem, figuring out what you know, what you don't know, and what you need to do to bridge that gap. That is EXACTLY what software development is.

So ANY software development is nothing but math: Problem solving, logical reasoning, critical thinking...pure mathematics.

[chris webster]

fred rosenberger wrote:I only skimmed the first article Chris linked to, but I have to strongly DISagree - with a caveat. I think math is critically important for all developers...however, I think math is a much broader topic that most. ... But to me, math is about logical thinking. It's about analyzing a problem, figuring out what you know, what you don't know, and what you need to do to bridge that gap. That is EXACTLY what software development is. So ANY software development is nothing but math: Problem solving, logical reasoning, critical thinking...pure mathematics.

OK, I see your point, but if we are widening the definition of "mathematics" to cover all "problem solving, logical reasoning, critical thinking", then we might equally include philosophy, musical theory and any of the sciences from psychology to physics as well. You are absolutely right that as software developers we need to apply those general skills constantly, but I'm not convinced that we make much conscious use of more specific mathematical skills (or even CS algorithms etc) in a lot of routine software development, i.e. the kind of CRUD and web applications described in the blog entry.

Is maths vital for routine software development (CRUD/web applications)? Probably not (IMO) provided you can acquire those skills in logical thinking etc some other way.

Is maths helpful for routine software development? Probably.

Is maths helpful for non-routine software development? Absolutely.

But that's just my view, so maybe I've just been coasting along in a sheltered backwater all these years. It's probably time to start working my way through Project Euler!

[Jayesh A Lalwani]

Someone here had posted this link before (I forgot who exactly). This blog makes a case for blue collar coders.

I think to some degree, the software engineering profession as a whole is shooting itself in the foot by requiring all software developers to be highly trained. We need software engineers to be analytical, and problem solving skills, because a smart software engineer is a flexible software engineer. You can take a smart person, and throw him/her into any project, and s/he will be successful. However, most day to day jobs in software engineering don't require analytical thinking. If you have already learnt a toolset, and you are given a problem that fits the toolset, you can blindly apply the toolset to the problem, and you can implement the functionality rather quickly. By requiring that every person who touches the code be highly analytical, we increase the cost of producing code

We do need people with problem solving abilities, but it would be beneficial to have people who know the tools focus on day to day menial jobs, and have software engineers focus on actually solving problems.

To draw an analogy, the term "engineer" used to mean "the person who drives the engine" (well it still does. train drivers are called engineers). It used to be that the machines that engineers built were so complicated that you needed engineers to drive the engine. You needed (what was at the time) white collar workers do the menial tasks of operating the engine. However, over time, the engineering profession grew so that engineers stopped driving the engine, and designed the engines so that someone coming out of trade school could be taught to drive the engine, and engineers could focus on designing well performing engines. Heck, car engines are so simple to operate now that 16 year olds can operate them.

IMO, the software engineering profession is at the same stage. Our tools and techniques are so complicated that we need an engineer to use them. The engine is so complicated that you need an engineer to drive it. It would be good if software engineers could get out of the drivers seat, and focus more on developing tools that blue collar workers can use to implement the end product.

[Jeanne Boyarsky]

Jayesh A Lalwani wrote:We do need people with problem solving abilities, but it would be beneficial to have people who know the tools focus on day to day menial jobs, and have software engineers focus on actually solving problems.

I'm curious what you consider a menial job in tech. I interview "developers" who can't write a simple loop. And some of them I believe really are "developing" - in that they are assembling things, copying heavily from examples and the like. But I don't have any use for someone like that in my shop.

Even boring tasks like "convert this from EJB to Spring" require problem solving skills. Figuring out what to do when it doesn't work, researching, trying out different things, etc.

[Bear Bibeault]

Yeah, us stoopid web developers ain't needing to know nuthin.

[chris webster]

Jeanne Boyarsky wrote:...Even boring tasks like "convert this from EJB to Spring" require problem solving skills. Figuring out what to do when it doesn't work, researching, trying out different things, etc.

I think we're drifting back to the old problem of what the best predictors are for a good developer with those problem-solving skills. Is it university-level maths? A CS degree? Hands-on experience? As far as I can tell, it can be all or none of those things. I'm just a grunt developer myself, and would not claim to be any kind of guru, but if even I am spotting these problems - CS graduates who can't code, experienced developers who understand nothing, developers with no interest in extending their skills etc - it suggests we have a real problem in this industry in figuring out what makes a good developer.

As for the blue-collar/white-collar divide, I'm not sure we can afford to take such a rigid approach. Most business application projects don't require an MIT graduate (or a JavaScript Ninja ) to implement routine functionality. But it's all too common for the "easy" tasks (that Jayesh's blue-collar developers might handle) to become more complicated, so we still need a fundamental level of problem-solving skills, however you acquire those skills and whichever branch of the industry you find yourself in.

In any case, most of the JEE projects I've worked on in recent years have already had that kind of divide, with "white-collar" architects and designers flinging UML and RUP documents over the wall to "blue-collar" developers, who then discover that most of this stuff doesn't actually work in practice. Then you really need those problem-solving skills - but that's a whole other rant!

[Jayesh A Lalwani]

Jeanne Boyarsky wrote:

Even boring tasks like "convert this from EJB to Spring" require problem solving skills. Figuring out what to do when it doesn't work, researching, trying out different things, etc.

Right, you have given them a very broad problem statement, and there are many ways of doing the same thing, which is why you need someone who is smart enough to figure out a good way of doing things. OTH, lets say you had a 2 or 3 ways of implementing spring services. Everyone in the industry implemented it in the same way. We could train people to implement the services in those 2 or 3 ways. They don't need to know how it works, or why it works. They just do as they are told. You, as an engineer know when to use each of those methods, and when not to use. You apply your analytical skills to pick a method, and go to the guy and tell him to apply this method. In the meantime, you might have a nagging feeling that things can be done better; that these 2 or 3 things that you have in your toolset don't cut it. You work on a 4th toolset, discuss it with other engineers, maybe even try it out, and then invite other engineers to look at it. They might go, that looks interesting, but I bet we can go a little better if we do this, or they go wow this is awesome, let me use it. If an idea is good enough it gets widely adopted


Trying to use another analogy; my brother is an architect, I'm an architect; he's the kind of architect who designs buildings; I design software. His work requires no less problem solving than mine. When he needs to design something, he needs to figure out how he can design something that fits the contours of the land, and also meets the clients needs. He needs to figure out how he can get the building materials and machinery in the space. I look at the people who work under him, and they aren't that educated. The foremen are literally the smartest guys in his crew, and all they know is how to read his plan, and execute it, and how to tell if things are going wrong. That's the extent of their problem solving skills. The foremen dont have bachelor degrees. they have either gone through trade school, or worked up as laborers. So, how is he able to solve problems that are as complicated as mine using people that are half as educated as my people? The difference is that he isn't designing everything from scratch every time he has a new problem. For each category of problem, he has couple of things in his toolset, and he picks between them, his foreman knows how each of these work, and all he needs to do is explain to him which method they are going to use today, gives him the plan, and walks away. Once in a blue moon, he needs to try something new, and in that case, he literally becomes the foreman.

Why can't we do things like this? It seems to me that when we design thing, we are constantly reinventing the wheel. I have to say though that we are getting close to standardizing our toolsets., but the problem is that we are evolving the toolsets so fast that it is impossible to train someone on it. As of right now, we look for smart guys not because the problems we give them are hard, but because we want someone who can pick up new technologies fast. IMO, the software industry can scale up a lot more, if we slow down.

[chris webster]

Jayesh A Lalwani wrote:...Why can't we do things like this?

As far as I can tell, many people are doing things like this more and more these days, but it doesn't work.

[Junilu Lacar]

Jayesh A Lalwani wrote:... but it would be beneficial to have people who know the tools focus on day to day menial jobs, and have software engineers focus on actually solving problems.

I know where you're coming from although your choice of words is a bit unfortunate. IMO, there is no such thing as a "menial" job when you're doing software development. You were probably referring to the tedious, nitty-gritty tasks that require intimate knowledge of tools or specs but those are far from being menial: everything we do requires some level of skill, thinking, and knowledge. I'll give you an example: whenever we get a security-related exception in our application that has to do with a missing Java security policy, I usually ask one of my teammates to fix it. This is not because I think it's a menial task and below my pay grade, it's because he's the one who knows best where to go and how to fix it. I tend to not want to bother with those kinds of details because I like to think in more abstract, big-picture terms. That's not to say that I don't have in-depth knowledge of other things though. Ask me about Struts and Tiles and how they work and I can give you nitty-gritty details. Ask me about the Spring framework and I can talk to you about it until you get bored. Different people are interested in different things any varying degrees. That kind of diversity on a team, IMO, is a good thing.

As to the OP, I also tend to agree with the article that Chris cited. I have found that the more you strive to be a generalizing specialist, which I believe you have to be if you want to advance in your career as a developer, the more you have to choose what kind of details you really want to know inside-out and which ones you can leave either for others, if you are so lucky to have them, to figure out or figure out on a now-I-need-to-know basis. Math is one of those things where it's good to have a broad understanding so that you can at least know that there is some kind of math-based solution available, then go into a now-I-need-to-know mode to figure out the details. I can't give you specific examples off the top of my head but I know this approach has served me well over the years, especially with more difficult problems. YMMV.

[Junilu Lacar]

Jayesh A Lalwani wrote:Why can't we do things like this? It seems to me that when we design thing, we are constantly reinventing the wheel. I have to say though that we are getting close to standardizing our toolsets., but the problem is that we are evolving the toolsets so fast that it is impossible to train someone on it. As of right now, we look for smart guys not because the problems we give them are hard, but because we want someone who can pick up new technologies fast. IMO, the software industry can scale up a lot more, if we slow down.

Our industry is way too dynamic to slow down. In many instances, solutions create more problems and it just expands exponentially from there.

The analogy between construction and software development has long been shown to be flawed in many ways. We don't need the equivalent of unskilled labor in SD. That's what gets us in trouble all the time. We need more skilled people. We need more people who can think. And we need to pay attention to how we form our teams.

IMO, a team needs at least one senior person who can provide the overall vision and keep that vision from becoming fragmented over time. Having two or more senior people can be beneficial if they work well with each other and their skills and specializations complement each other. The rest of the team can be less experienced but they still need to have skills and knowledge. Like I said before, there are no menial jobs in SD. Everyone on the team needs to think, it's just that they have to think at different levels of detail. They still have to be able to work with each other to make everything come together as one cohesive and coherent train of thought though. That's where the challenge lies. Telling the story completely and correctly when you have many different storytellers in the mix.

[Paul Anilprem]

Jayesh A Lalwani wrote:

Jeanne Boyarsky wrote:

Even boring tasks like "convert this from EJB to Spring" require problem solving skills. Figuring out what to do when it doesn't work, researching, trying out different things, etc.

Right, you have given them a very broad problem statement, and there are many ways of doing the same thing, which is why you need someone who is smart enough to figure out a good way of doing things. OTH, lets say you had a 2 or 3 ways of implementing spring services. Everyone in the industry implemented it in the same way. We could train people to implement the services in those 2 or 3 ways. They don't need to know how it works, or why it works. They just do as they are told. You, as an engineer know when to use each of those methods, and when not to use. You apply your analytical skills to pick a method, and go to the guy and tell him to apply this method. In the meantime, you might have a nagging feeling that things can be done better; that these 2 or 3 things that you have in your toolset don't cut it. You work on a 4th toolset, discuss it with other engineers, maybe even try it out, and then invite other engineers to look at it. They might go, that looks interesting, but I bet we can go a little better if we do this, or they go wow this is awesome, let me use it. If an idea is good enough it gets widely adopted


Trying to use another analogy; my brother is an architect, I'm an architect; he's the kind of architect who designs buildings; I design software. His work requires no less problem solving than mine. When he needs to design something, he needs to figure out how he can design something that fits the contours of the land, and also meets the clients needs. He needs to figure out how he can get the building materials and machinery in the space. I look at the people who work under him, and they aren't that educated. The foremen are literally the smartest guys in his crew, and all they know is how to read his plan, and execute it, and how to tell if things are going wrong. That's the extent of their problem solving skills. The foremen dont have bachelor degrees. they have either gone through trade school, or worked up as laborers. So, how is he able to solve problems that are as complicated as mine using people that are half as educated as my people? The difference is that he isn't designing everything from scratch every time he has a new problem. For each category of problem, he has couple of things in his toolset, and he picks between them, his foreman knows how each of these work, and all he needs to do is explain to him which method they are going to use today, gives him the plan, and walks away. Once in a blue moon, he needs to try something new, and in that case, he literally becomes the foreman.

Why can't we do things like this? It seems to me that when we design thing, we are constantly reinventing the wheel. I have to say though that we are getting close to standardizing our toolsets., but the problem is that we are evolving the toolsets so fast that it is impossible to train someone on it. As of right now, we look for smart guys not because the problems we give them are hard, but because we want someone who can pick up new technologies fast. IMO, the software industry can scale up a lot more, if we slow down.

I agree with what you mean. The problem is in the s/w industry people reinvent the wheel because they can. Unlike building a wall, every s/w problem offers an opportunity to be solved differently. But you are not off the mark. I know SAP "implementors" who have no advanced (i mean above 12th grade) math knowledge or a CS degree and they still get paid quite well because they know very well how to solve a particular problem using one of the solutions already researched by SAP. They work with a definite set of problems that have a definite set of solutions. But you throw an off beat problem, they might struggle with it.

So basically, it really depends on what kind of shop you are running.

[Paul Anilprem]

Junilu Lacar wrote:

Jayesh A Lalwani wrote:... but it would be beneficial to have people who know the tools focus on day to day menial jobs, and have software engineers focus on actually solving problems.

I know where you're coming from although your choice of words is a bit unfortunate. IMO, there is no such thing as a "menial" job when you're doing software development.

While "menial" is indeed a questionable word, the Y2K work that came India's way was very close. There really were people without any degree, armed with 3-6 months course, doing that work day and night. The point is, such work exists.

[Luke Kolin]

Jayesh A Lalwani wrote:Trying to use another analogy; my brother is an architect, I'm an architect; he's the kind of architect who designs buildings; I design software. His work requires no less problem solving than mine. When he needs to design something, he needs to figure out how he can design something that fits the contours of the land, and also meets the clients needs. He needs to figure out how he can get the building materials and machinery in the space. I look at the people who work under him, and they aren't that educated. The foremen are literally the smartest guys in his crew, and all they know is how to read his plan, and execute it, and how to tell if things are going wrong. That's the extent of their problem solving skills. The foremen dont have bachelor degrees. they have either gone through trade school, or worked up as laborers. So, how is he able to solve problems that are as complicated as mine using people that are half as educated as my people? The difference is that he isn't designing everything from scratch every time he has a new problem. For each category of problem, he has couple of things in his toolset, and he picks between them, his foreman knows how each of these work, and all he needs to do is explain to him which method they are going to use today, gives him the plan, and walks away. Once in a blue moon, he needs to try something new, and in that case, he literally becomes the foreman.

Why can't we do things like this?

I would argue that we have. The equivalent to the foreman in our world is the compiler, and I would venture that it is far more consistent and reliable (but less able to work around silly mistakes we make!) We've automated the blue collar work out of existence.

Cheers!

Luke

[Andy Jack]

chris webster wrote:I'm just a grunt developer myself, and would not claim to be any kind of guru, but if even I am spotting these problems - CS graduates who can't code, experienced developers who understand nothing, developers with no interest in extending their skills etc - it suggests we have a real problem in this industry in figuring out what makes a good developer.

It seems that these could be the reasons behind what you said -
1 - High demand for tech people, but low supply of workers. So, people with limited experience or even mediocre people are being employed just to fill the void.
2 - I suspect that a lot of people get into IT/CS/Soft Engr jobs because of "high demand" and "good salary". I know many people who have no passion for this field, but are only there for the money.