I have.

A pre-commit hook in your revision control software to bounce changes which won't confirm does the job nicely with a

make style

target making achieving pre-checkin compliance painless.

Occasionally you need something which technically violates the style checker, although the need for a manual override via something embedded in comments like /* BEGIN CSTYLED */ /* END CSTYLED */

limits that to rare intentional occurrences.

That's a horrible idea if you can't get into the top 7 or so law schools.

About half of law school graduates can't get jobs as lawyers and many end up shuffling papers for $15 an hour. That might not be so bad in the grand scheme of things, although the average law graduate finishes their education with $150,000 on which student loan interest can run $1000/month so you'd need to live off $8.50 an hour to keep the principle from increasing which is poverty level.

"Like some Slashdot users, I began attending university last month for computer science.

Conversing with my college computer science peers (many of whom are quite nerdy), I have noticed that many of them are extremely arrogant. Upon introspection, I have come to the realization that I am also very similar to them and am very curious, but worried."

While a few of you are assholes for whom there's no hope, most of you are that way because you're young and not done growing up.

Your situation may be exacerbated by the college admissions process, where kids compete amongst each other to be in the top x% or 0.xx% to get in. Appearing to be better than the remaining xx.x% seems critical to your life.

Most of the real world doesn't work that way - you just need to get your work done well enough on time whatever that means.

"I have noticed similar personality characteristics on Slashdot. Where does this nerd arrogance come from?"

Many people are more obnoxious on-line where it's entertaining for them than in real life where it'd be a problem that gets in the way of relationships and promotions.

Having done software professionally for 20 years, delivered five non-trivial products built from scratch to customers for business critical applications (things like block storage on a shared nothing cluster of x86 boxes and a highly available cellular base station billing interface), and worked on at least a dozen other products I disagree (three big company re-orgs in 18 months and some consulting exposed me to a lot).

Fast or good is a false dichotomy. You can have both or neither and as an added bonus choosing "fast and good" also nets "less expensive" which is the mythical holy trinity.

Do things right and you'll make your initial profits sooner - either because customers start buying that product sooner or you pivot and get your next try out there in less time.

Software (whether packaged that way, as a service, or as a hardware appliance) products are about nested feedback loops within the larger business cycle of market needs leading to customers paying you repeating as you flesh out a complete product, build a surrounding ecosystem ecosystem, go vertical, etc.

Within that are the loops surrounding things engineers identify with like writing software, writing tests, fixing bugs, and making releases.

The things you do to make maintainable code reduce the time it takes to deliver a viable product to customers on the first AND following cycles.

Unit and regression tests reduce the time to fix the bugs you inevitably introduce. There's much less wasted effort when you write code, the relevant tests find a problem immediately (as opposed to waiting for a release to drop to QA or going through multiple release candidate - QA cycles followed by shipping to a customer that finds the problem), you have more information which leads to a quicker fix, and you have no context switch overhead. They also give you more latitude in what the people you have work on because there's little risk added by people working on unfamiliar code when there's enough pre-checkin coverage to make getting bugs to QA or customers unlike.y

Meaningful comments surrounding what you're doing facilitate neural pathway formation leading to a deeper understanding, more "aha!" moments, and fewer bugs. They get you back on track sooner after the inevitable context switch for tactical issues.

Refactoring reduces your bug count and time spent on problems because non-existing lines of code can't have bugs.

Things continue to improve as you get nuttier:

I was turned on to simulation (link your shipping product code to mock objects at a low level gaining control over scheduling (make it deterministic and get atypical timings via pseudo random or state search methods)) and model checking by a Digital Systems Research Center alumni I was working with on another clustered block storage appliance. It seemed neat and useful until I spent an afternoon moving a lower piece of the stack into the simulated environment and found the buffer reuse problem which had been holding up our release for a month. "Neat" became "you'd be dumb not to" for some class of software. In a subsequent commercial life I did the right things again and solved memory corruption problems which showed up under certain event orderings in hours where co-workers did not and took weeks for the same sorts of issues.

Tool building can pays huge dividends too:

A good logging system is not core to your business and something which people usually skip. However in practice it takes much less time to build a system which logs 300,000,000 (on a four year old pre-production dual socket Nehalem box) entries a second via a printf API into a circular shared memory buffer which survives process termination and allows development trace level logging in a production real time system (at only 300,000 user IOPs per second you could have 50 entries per operation before you got to a 5% performance degration and at just 10 you're pushing the measurement noise floor) and fix your first bug depending on the order of events (those take longest) than to fix a similar bug without the system. Hierarchical log categories (like protocol/replication/recovery, protocol/replication/meta_storage, etc) allowing inclusive or exclusive level based filtering (trace level for protocol except protocol/replication/messages which would be too noisy) get you there faster at effectively zero cost.

>Any other ways to find out code quality beforehand?

Absolutely.

That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).

When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.

You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.

One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.

This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.

In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.

I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)

This isn't interesting news.

1. Salary is a smaller subset of compensation in larger companies and becomes less significant as you move up the food chain.

At the last big company I worked for I took home $35K less salary than at the startup which followed, although if neither stock prices nor salary went up salary would have been less than 60% of my total compensation over 4 years and I'd have done $52K/year better.

2. Salary is highly dependent on where you are in your career making the average within an organization largely a function of typical job level. At the least startup I worked for I was the only early hire under 40 and we were all at the principal engineer / director experience level. At the last big company only three of the engineers I worked with (maybe 1 in 5) were over 30 and lots of people were in their first job after school with matching entry level titles and compensation. When you need six engineers who'll each be responsible for a component you need seniority, can hire that many senior guys, and will have a higher average salary. When you need thousands of engineers and most groups/projects have 4-8 people you don't need the experience, couldn't hire it, will be lucky to make one senior hire after 6-12 months of trying, and will have a lower average salary.

3. Aptitude (Demarco and Lister comment on this in Peopleware if you want a formal cite) is usually fairly consistent within organizations and that can be worth another 25 - 30% (although IIRC Demarco and Lister only report a 10% pay delta). Exceptions exist in good organizations where you might get a few stars that are much better and bad organizations where B grade people hire C grade people to limit competition.

>What does the Slashdot crowd see as the best path to fame, wealth and full employment for gray-haired old coots who love to program?"

Those are orthogonal goals.

Fame: Free software. Wealth is not likely to follow. You can probably make a career out of it though.

Wealth: Startup with exponential growth. $1000 of monthly revenue is $25M/month after four years at a 5% weekly growth rate. In some one else's venture funded company just 0.5% of a 1B market cap is $5M in long term capital gains. 25% left of your own company which is not trying for VC sized returns with a $20M liquidity event is the same.

Full employment with a good salary (mid-career you can break $200K if you're willing to work for large companies): do something hard well which leverages your decades of experience that let you compete against youngsters even though you cost more. My thing is systems software for business critical applications with an emphasis on distributed systems and high availability. I've done cellular base station infrastructure, digital video for the broadcast market, block storage on a clusters of x86 PCs, light weight key-value storage on spinning disks and flash, and am now doing enterprise grade cloud backup. Although I confess to having worked on one C# project and a couple in Java the rest has been evenly split between C and C++. Language and libraries are not the hard part and I've worked in groups where nearly everyone is over 40.

A paycheck now: Join a contracting/consulting shop which takes a third off the top.

While learning new technologies is fun and neat, with anything trendy where the meat is in the mechanics of how you do things not what you're doing you will be competing with young guys who can get the job done well enough and are more enthusiastic, compliant, and willing to work for less money.

It depends on how you define 'programmer'.

Most people could learn to do trivial (count 1 to 10 in a loop) and simple things.

OTOH less than 1% of professional programmers whose resumes are filtered by recruiters paid on contingency have all the aptitudes necessary to do well in the commercial environments I work on (I think a larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal and not go through a recruiter).

Those aptitudes are

1. The ability to think logically, identify edge conditions, and express that

2. The ability to deal with indirection

3. The ability to apply knowledge to engineering problems.

4. The ability to grasp parallelism

I have a set of questions covering these which changes some with time. There aren't any trick questions here - engineers which do well tend to make it through the first question in under 10 minutes and the rest under 5 after which we can talk about their work history and other things. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer.

Such things should be pre-requisites for a computer science degree but aren't because too many people fail when they are and that's bad for the department's cash flow.

My favorite professor taught data structures with her TAs linking students code into their automated test suites with grades based on whether their code actually worked. Supposedly 1/3 of the class failed. Graduates of that program were generally worth hiring.

She was replaced by a more lax instructor that didn't do that and our hire rate went way down.

Starting compensation packages at the big silicon valley companies (Apple, Google, Facebook) for new graduates are breaking $100K

http://www.netpaths.net/blog/starting-salaries-of-top-technology-companies-apple-google-microsoft-facebook/

Every mid-career position doing systems software I've talked to people about over the last decade in Boulder, CO; Seattle, WA; and Silicon Valley has paid better than that.

Senior staff and principal engineer roles (actual as opposed to title inflation side effects, with technical leadership responsibilities and 15+ years of experience getting there) are breaking $200K in Seattle and the SF Bay Area - often with much of that stock, although with privately held companies it can be all cash.

Key differentiators here are

1. It's all core not context using Moore's (as in _Crossing the Chasm_) definitions. Core is what your business is where doing it better confers a competitive advantage, like where you sell storage appliances and they're faster/more reliable/easier to backup than the competition's products. Context are other things that you need to do although doing them better doesn't confer a competitive, like having an on-line shopping site. If it takes 10 ms to complete a user checkout instead of 100ms you won't sell any more product.

2. Meaty. Some things are harder to do well enough than others. Scattering enterprise data over a shared nothing cluster and not ever loosing any is harder than a smart phone app to play Pictionary (TM).

3. It's all in geographic areas where lots of that sort of thing is going on. I'd recommend Silicon Valley because being here radically increases your chances of finding a good combination of product life cycle, interesting technical challenges, and viable business plan. The weather is great too - I wear shorts year round. Of course, $100K doesn't go as far where apartment rent can run $2000-$3000. I bought myself a nice double wide mobile home so I could have a nice place to live without a cash flow situation I objected to.

Such positions being open to you are a separate issue. About 1 in 200 resumes received from recruiters paid on contingency filtered for people who do meaty things belongs to some one worth hiring due to deficiencies in things that seem to be aptitudes not skills and should be pre-requisites for a computer science degree although weeding people out there cuts the department budget. Those aptitudes are

1. The ability to think logically, identify edge conditions, and express that

2. The ability to deal with indirection

3. The ability to apply knowledge to engineering problems.

4. The ability to grasp parallelism

I think a much larger percentage of engineers are good, although most of them already have jobs and are likely to join a former co-worker at a place which has been verified to be good when that becomes sub-optimal.

1. 100% binary compatibility with Windows binaries. Many people have some "killer app" that they need to run which is Windows and/or Mac only.

As it stands, I need to boot into Windows to run Sketchup.

2. 100% binary compatibility with Windows device drivers.

My Linux wifi driver often flakes out talking to one access point with a panic which requires manual intervention. The last Fedora I tried progressively increased my fan speed running X until I had a jet engine until the next reboot. My Windows drivers don't do that.

3. 100% binary compatibility with Linux, including 32 bit binaries on 64 bit systems.

It's a pain in the butt as a company to deal with multiple Linux versions in terms of builds, test, and support. It's a pain as user where the software you want has the wrong flavor.

I have 32 bit Firefox (with 32 bit only plugins that I need for reliability) mostly working on a 64 bit Debian, although some of the libraries have hard-coded paths in them which produce frightening error messages and I never got the Java plugin to work which I'd need to use my company VPN.

The (non) viability of this (as a hobbyist I don't want to waste my life reverse engineering Microsoft APIs, and as a business I don't care whether my servers run desktop applications) is a separate issue.

That's a naive simplification that's not really true. Software development is _not_ a zero sum game and time doing things which "don't ship to customers" both reduce total time and make it more predictable so your time commitments are less likely to become harsh.

Your milestone is _not_ code complete. It's delivering a product to customers which meets some requirement set including quality. The time to get there is something like

Requirements
+ Functional spec
+ Write and comment tests
+ Design
+ Write & comment code
+ Manual test execution
+ New feature bug count * (interrupt overhead + average time to fix new bugs)
+ Regression count * (interrupt overhead + average time to fix regressions)
+ Bug count from previous releases * (interrupt overhead + average time to fix previously latent bugs)

where some steps may be trivial and there are nested feedback loops around others.

The terms are neither constant, functions with project size as the only input, nor independent.

Generating a good comment causes your ideas to flow through other parts of your brain so you develop a better understanding of what's going on thus reducing the defect rate in terms of new bugs.

Having done so before means you have a better understanding of what was already going on, so you have fewer regressions and where they happen there's less context switch overhead figuring out what was going on so you can fix them.

The reduced bug count from previous releases multiplied by lower interrupt overhead means you loose less time there.

Better test coverage means more bugs are found early where the time to figure out what you were doing when you caused them is lower. Lower level test coverage means everything is more isolated so the time to correct each one is lower.

Designing for validation so that's manageable encourages better encapsulation within components and smaller component size which reduces both bug count and the time to correct each one.

Etc.

Interesting problems to solve, flexible hours, and six figure compensation packages where willingness to work for a big company can make the first digit more than '1'.

I can't name any other profession where you can get most of that with a four year degree (or less; almost every place you want to work cares more about you knowing the things you should have learned in engineering school than having the degree) where being a doctor or lawyer could net the pay and interesting problems.

That is somewhat better than most entrepreneurial experiences which lead to zero.

When recruiters contact me about something potentially interesting (technically challenging, good point in the company life cycle, business model lacking holes I could drive a train through) I arrange a meeting with an engineering VP or CTO and talk about what's going on regardless of how content I am with where I am.

If a pivot happens that changes my job unacceptably and/or money runs short I can then turn that into a job.

>This "building an app is like mass producing a chemical" philosophy is one reason why most software shops have insane amounts of unneeded documentation and overhead

In 20 years working as a software engineer I've yet to encounter a software shop with insane amounts of unneeded documentation. The majority of software organizations I've dealt with had inadequate documentation and process which led to lower quality for customers, lower developer throughput, and unpredictable release schedules.

Usually this comes from deep seated religious beliefs among executive teams and mid-level managers. To quote one CEO "Test code doesn't ship to customers." He practiced what he preached, directing employees to build product and not test too much. Another company managed a two billion dollar market cap from a product very similar to one the he abandoned because the schedule kept slipping and it never worked well enough (although engineering staff kept strongly suggesting hardware validation).

Nothing can change that religion. You can apply better process to your own projects and illustrate order-of-magnitude lower defect rates and time to fix bugs that result from that compared to similar sized projects in the organization without the process. You can talk about the business benefits from positive experiences in other companies. You can sometimes get them to read books like _The Clean Coder: A Code of Conduct for Professional Programmers_. You can share your amusing anecdote about the company you didn't work for because one of the founders did not believe in unit tests so you knew they were going to crater due to low quality and long unpredictable release cycles which had their VCs rescind funding due to customer issues with quality and long and unpredictable delays for bug fixes. You can get other executive team members on the right side and attempt an intervention although the same skills of persuasion which get tens of millions from investors work to move them back. You can go to the board of directors although they're friends with the executive team and it doesn't end well.

Occasionally it's just ignorance. Software engineers can go through a lot of positions without stumbling across someplace that does a good job. This is easily fixed - once competent people have seen how much tedium process removes from their lives and how it lets them focus on interesting problems they get with the program.

While software development is an art, there are accepted processes not too different from mass production that make higher quality, shorter delivery times, and more predictable schedules likely. Although that doesn't sound like fun they do allow the engineer to spend more time on art (which is fun) and less on mechanics so it's a win-win-win for customers., company, and coder.

I have encountered unneeded overhead which can be another facet of the same problem or something else. Sometimes companies grow too fast and create extra positions filled by people that need to justify their jobs. Sometimes the executives who direct less testing become unhappy with the unpredictable product cycles which result and decide to apply the daily meeting (except for 1-2 hours) from the agile world without the things which make agile work.

Once when consumer high-speed internet became available with a flat monthly rate. Before that I paid $75 + phone lines on both ends for my share of a 64K ISDN connection to a not-for-profit ISP run by people with ties to the same university.

When I moved after that.

Often there isn't a real choice - where I am now I can have Comcast with at least 20 mbps down and 6 mbps up, 768K DSL which isn't fast enough to stream video, or something expensive and slow from a satellite provider.

Where there is it's not worth the hassle dealing with whatever will be wrong.