most companies don't know how to value the contributions of software developers. i'm not actually sure they know how to value the contributions of most employees, period, except for salespeople. However as a dev, I'm biased some. I do think the potential for high value contributions, and the ability to avoid even costlier mistakes, is higher in the IT/dev dept vs other corporate departments.
Several years ago I was offered $60k at a company as a developer. I was coming to them with, at that point, 12 years of web development (backend, php, etc). I pointed out that $60k was not something I thought was reasonable for what I was bringing. "This is what everyone starts at here," was the reply, and I learned that was their starting salary for 'just out of college' devs. They hadn't hired any senior-level devs before (but had dozens of devs), and didn't even know how to put a value on the skills one brought to the table.
I've learned they've since changed their policies some, but that policy actually did a lot of damage to their rep in the local scene, and it was hard for them to get good devs for a while. The few I knew who were really good generally didn't start there, or started, then left after a bit. But... because I knew people there, I learned about their internal stuff. I was (sort of) shocked at how many basic dev mistakes they made, which ended up costing them extreme time/money to fix months or years later. These were rather elementary mistakes in most cases - I'd made them 10 years earlier myself in some cases.
How does one put a value on the savings experienced devs bring to a company, in terms of simply not making bone-headed decisions which cost a lot to fix later on? This is not saying I'm perfect - of course I'd make some mistakes. But mine would be harder to detect ;)
Lastly, somewhat relatedly, devs just coming out of school are almost never taught a few basic skills which are nearly universally required - how to break down a project in to smaller parts, debugging techniques (how to think about debugging, not particular tools), testing (including how to think about making code testable the first time), and version control concepts (again, not a particular tool, but the importance of version control). I'm seeing devs come out of school with degrees who have never heard of git/svn/cvs, nor understand why they need version control ("it's just me on a project").
> How does one put a value on the savings experienced devs bring to a company, in terms of simply not making bone-headed decisions which cost a lot to fix later on? This is not saying I'm perfect - of course I'd make some mistakes. But mine would be harder to detect ;)
Learning how to translate your value as a developer into dollars is an extremely useful skill that will help you gain a lot of respect and earn more. Speaking from experience, people are a lot more impressed when I say "I saved my last company $3MM in 8 months" than if I say something like "I set up a reporting architecture which allowed us to automate a lot of work and greatly reduce the number of errors, plus create new reports faster."
So how do you actually figure out your value? Here are some methods:
1. Time savings. Almost everything a developer does reduces the need for other people to spend time working on any given project. Ask a few people how much time they save per week thanks to your software, and multiply that by the number of people using what you've created.
2. Sales increases. Compare companies in the industry that have great development practices to companies that have terrible practices. Find out what features have helped increased sales, and point out how these features couldn't have been created without fantastic developers available. You'll find that a case for hiring good programmers. almost writes itself.
3. If you want to get really advanced, take (1) and (2) and actively seek projects where you'll be make major contributions to the company's bottom line.
This is also the way that you can get paid what you are worth by a small non-technical company that knows nothing about software development and thinks of programmers as other employees that should be a paid a middling salary.
Granted the sword cuts both ways. A lot of companies really don't have the kind of business where a skilled software engineer can save enough money to justify a 6-figure contract, but on the other hand, a lot of them do and just don't know it.
#3 is the center of patio11's usual advice for programmers who want to make more money[0]. It boils down to "find a part of the company that is making money, go there, and show them how your contribution helped make more money."
The one thing I would add is you don't need to be in a profit center of the company, though it helps. Even administrative roles have a lot of ways to contribute to the bottom line (the $3MM example I gave was in a reporting department!)
You don't need to be in the profit center of the company, but, and this is a big but, when you are not in the profit center of the company you, your colleagues and your department are seen by the CFO and accounting side as an expense and not a cost.
Being seen as an expense in many companies means that there are budgets and less perceived room for negotiating by those deciding your salary. They have a budget to meet. It's not like they can easily go to their superior and say "Hey, if you increase my budget for salaries X, I can reduce the company's expenditures by 2X". Unfortunately budgets for most non-core departments only go down, unless the demand for the service that non-core department by the core departments go up, i.e. "In order to offer 2X capacity, I need 2X the budget"
Plus, you generally never want to be in the non-core part of any company/industry because the quality/talent of the people you work with in the profit center of a company/industry. It's simply much harder to surround yourself with good people.
Precisely. It's a business, treat it as such. If you want to focus on The Holy Craft Of Programming, get a PhD and good luck with the academic track. Otherwise, go into business as a businessman who happens to be an excellent programmer. (Assuming you don't want to be underpaid and unappreciated your entire career.)
I'm not even sure they know how to value salespeople's contributions. Compensation in sales is often in the form of a lower salary combined with percentages of sales and/or bonuses for meeting targets.
When a salesperson makes a sale, what percentage of that sale has the salesperson brought in? How much of the sale was actually generated by marketing, design and manufacture? Similarly, if they fail to make a sale, how much of that failure is their own?
Good points. At the very least, there are some processes in place such that if you directly bring in more revenue to the company, you generally share in it as a salesperson. Usually not so as anyone else in a company, unless you've got profit sharing of some sort.
It's somewhat worse as a non-salesperson, in that, if you make a sale, you get a commission, and it's yours. The rest of the incoming money/profits go in to the company, but you as employee X generally have no say how the company operates. The profits that should be being funnelled in to XYZ, instead go to ABC, which everyone else can see is a dumb decision, but ... you can't influence it. The salesperson can't either, but they've gotten a direct benefit for their part already (higher/more commission).
That's just saying that companies cannot value the contributions of salespeople vs "non-sales". Which is isomorphic to "companies cannot correctly value non-sales employees" anyway. You're not arguing with the case, just restating a corrolary.
Between salespeople, you can certainly tell who is making more money than their peers.
That's a good point - if you can't calculate the value of anyone but salespeople, then you can't calculate the value of salespeople either.
Calculating the relative value of one salesperson vs. another doesn't say anything about how much value either of them brings to the company, apart from the likelihood that one of them brings more than the other.
Re: basic skills. I think we have a big problem with schools. Why don't they teach how to test? Why don't they teach how to debug? Really, what are they teaching that is more important than these basic skills?
They do teach those things, but a classroom context can not replicate the reality of large-scale long-lived multi-developer projects. There's just not enough time in a college degree to give any realistic approximation of that, plus what does the academic world know about that? They're not qualified to put together that curriculum, and what's the point anyway since you can learn it in the trenches at any company out in the private sector.
Instead CS focuses on theory. The distillation of the most important theoretical foundations of the field is actually a pretty useful thing to get, because you won't find it anywhere else but in a University. You can Google all these things sure, but first you have to know what they are. Having the foundation of these things will be quite useful over the course of a career when best practices for testing, debugging and platforms themselves will change dramatically. A couple decades down the line, sure you won't remember the details of what you learned in this class or that, but sometimes just the tangential awareness of something such as the existence of dynamic programming algorithms will give you the hook needed to google around and find an efficient solution to something which an untrained programmer might never know how to find.
Computer Science courses must maintain a strong focus on theory. An entire CS course can be conducted using Knuth's TAOCP, paper and pens only. The reason being that Computer Science is a highly specialised extension of Applied Mathematics into computing environments. These courses produce researchers. Programming, software development and project management are out-of-scope.
Software Engineering courses are meant to cover the real world application of the Computer Science discipline, Project Management discipline and a broad variety of other topics relating to business and management. These courses produce software developers and software project managers that mostly sit in modern interpretations of the cubicle farm developing the 150th interpretation of a business productivity app.
Experience levels
3-5 years at University is not enough time to gain expertise in the wide range of areas that make someone a brilliant hacker. The best hackers graduating from University tend to have 10 or more solid years of diverse and highly creative experience through hobby involvement (open source development), school experiences and perhaps relevant paid work.
Work experience tends to lack the diversity and creativity required to develop and maintain impressive hacking skills. Changing jobs every 2 years or maintaining a strong open source/hobby interest can counteract this problem.
Suggestions for higher education courses
1. Treat Computer Science in the purest form -- an extended Applied Mathematics course.
2. Encourage students to complete a Computer Science and Software Engineering course together. This approach ensures that students graduate with a decent understanding of essential theory: graphs, sets, complexity, algebra, etc and have a job prospect at the end.
3. Replace toy problems and short assignments in Software Engineering courses with longer real world experiences. Open source projects, student-owned start-ups and short stints of relevant paid work experience are a much better environment for applying theory and practising software project management principles.
4. Make it clear to students that learning should be a life-long goal. Diversity of experiences across completely different fields (example: marine biology, tourism and software development) is of particular importance.
There is no substitute for hard-won experiences, but debugging is a skill that can be taught. The academic world (well, some part of it) knows about debugging and is surely qualified to put together a curriculum. Really, go read "Why Programs Fail".
A lot of what I know about debugging I learned in the trenches, but I also learned a lot from that book. My question is that why I had to discover this book myself, instead of being taught.
In a CS class I took, we built a project over the course of a month. The TA's then introduced 5 bugs into the project, locked us in a room for 3 hours and we were required (individually) to find and identify the 5 bugs in that time. If you failed, they do it again a week later for a lower grade.
In my CS program they taught debugging, but the majority of what I learned about debugging happened in the lab. Working on the problem sets was a microcosm of debugging that transferred quite well to the professional world, but I suspect not all CS curriculums have as rigorous a programming practice as mine (University of Minnesota, based on the MIT curriculum: scheme, c, java, c++, perl).
I'm knowing people who are getting "web developer" certificates and degrees, and who also never hear the words "testing" or "source control". In 2012. Sad.
I made a bit less than that, but that was during the time my peers were still in college. By the time they were graduating, I had experience under my belt and was able to get a job that paid far more than a 'just out of college' salary.
Several years ago I was offered $60k at a company as a developer. I was coming to them with, at that point, 12 years of web development (backend, php, etc). I pointed out that $60k was not something I thought was reasonable for what I was bringing. "This is what everyone starts at here," was the reply, and I learned that was their starting salary for 'just out of college' devs. They hadn't hired any senior-level devs before (but had dozens of devs), and didn't even know how to put a value on the skills one brought to the table.
I've learned they've since changed their policies some, but that policy actually did a lot of damage to their rep in the local scene, and it was hard for them to get good devs for a while. The few I knew who were really good generally didn't start there, or started, then left after a bit. But... because I knew people there, I learned about their internal stuff. I was (sort of) shocked at how many basic dev mistakes they made, which ended up costing them extreme time/money to fix months or years later. These were rather elementary mistakes in most cases - I'd made them 10 years earlier myself in some cases.
How does one put a value on the savings experienced devs bring to a company, in terms of simply not making bone-headed decisions which cost a lot to fix later on? This is not saying I'm perfect - of course I'd make some mistakes. But mine would be harder to detect ;)
Lastly, somewhat relatedly, devs just coming out of school are almost never taught a few basic skills which are nearly universally required - how to break down a project in to smaller parts, debugging techniques (how to think about debugging, not particular tools), testing (including how to think about making code testable the first time), and version control concepts (again, not a particular tool, but the importance of version control). I'm seeing devs come out of school with degrees who have never heard of git/svn/cvs, nor understand why they need version control ("it's just me on a project").