While languages are easy, transitioning from language controlled resource management (as in languages with garbage collected language memory management) to programmer controlled (as in languages with garbage collected memory management that do nothing with other resources like file descriptors) is harder.
I've seen situations where "java programmer" graduates meet the real world with file descriptor leaks that bring down "enterprise" systems resulting in customer outages with pagers going off, and would much rather have ones used to dealing with their own resource management.
In an ideal world the language people would have used reference counting, but we don't live in an ideal world.
Private offices are far less expensive than the cost to productivity from open office environments.
1. IBM Research studied the problem, and found that engineers are 40% more productive in quiet private offices than open environments. At a fully burdened annual cost of $100-$200K per engineer open seating could cost you $120,000-$240,000 a year.
2. It can take fifteen minutes to enter a mental 'flow' state. Once you get a high enough interrupt rate it's difficult to get anything done until people go home for the day.
3. Open offices encourage unnecessary communication. Where people might find answers themselves they ask their co-workers because it's easy thus saving minutes for themselves at the cost of up to fifteen minutes from their co-workers.
>Clearly, very few people here have any enterprise-level Solaris experience. In terms of stability and performance I compare Linux to Solaris like you compare Windows to Linux.
I used Solaris in a cellular base station billing interface appliance.
Moderate thread use crashed it out to the ROM monitor (we gained usable stability and a 100X performance improvement by switching to an event driven scheme) and sequential performance through the file system was half that of Linux (it was good enough for our use).
You can pick anecdotal stories to support any hypothesis regarding operating system stability you want.
1. Contribute to a free software project which interests you.
This will allow potential employers to verify that you can program before bringing you in for an interview, and hopefully you'll learn something about writing maintainable code so your first paying employer doesn't bear the burden of getting you over those hurdles.
2. Network.
Maybe a local group of geeks gather weekly for beer. Maybe there's an interesting user's group. Meeting people at such groups make access to un-advertised positions or to some one in engineering (not HR) that can be intelligent about who to bring in for interviews.
The typical Microsoft/Eclipse/whatever GUI today is horribly wasteful: vast areas are wasted on window dressing, toolbars, menus, scrollbars...
I get around that by not using an IDE except to debug Java I've written. In vim each source file, build error log, or document is separated by one character whether they're arranged side by side or vertically and there's no scroll bar or mouse needed. For compiled languages the debugger gets one window with a couple pixels around it plus a scroll bar with watch expression display together with source.
If an emacs user taunted me about running my debuggers in a separate window I might be tempted to get the Conque plugin.
Any arbitrary limit on line width belongs in another century, and IME just results in developers who have a good reason to write a relatively long line messing around with awkward formatting hacks or truncating identifiers in order to obey the letter of the law.
While an arbitrary limit is bad, there's a point at which running into a limit generally means that indentation levels are getting too deep because function granularity is too coarse. You months or years later, your co-workers, and successors will all be happier if you fix the problem instead of trying to squeeze things into the 'letter of the law'. With name spaces and APIs having POSIX-length identifiers 80 characters is appropriate. 120 characters works for longer things.
A one-page function length limit with occasional exceptions is also a fine idea.
1. Professional organizations can offer affordable group plans to their members. One example is the Microsoft Alumni Network open to all former Microsoft employees. IIRC, their small business group plan was open to companies with 2 or more total employees which could be you and your spouse (paid to file your taxes or whatever).
2. Your single employee business can outsource its benefits to a PEO (Professional Employer Organization), some of which have no minimum company size.
Both options get you into large groups which therefore have relatively good rates for group plans, which is to say very expensive for young healthy people but relatively affordable for the rest of us.
Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).
You might get within an order of magnitude (days, weeks, months, years) without the low level design.
A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.
And an even smaller multiplier (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.)
Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.
drew@l-drew% man -k burn k3b (rpm) - CD/DVD burning application for KDE nautilus-cd-burner (rpm) - Easy to use CD burning for Gnome
Unfortunately, the yutzes putting together Linux distributions (this is Centos) don't always include the man pages:
drew@l-drew% which k3b/usr/bin/k3b drew@l-drew% man k3b No manual entry for k3b drew@l-drew%/usr/bin/nautilus-cd-burner drew@l-drew% man nautilus-cd-burner No manual entry for nautilus-cd-burner
Most "software engineers" can't solve simple problems in a reasonable time frame, don't check corner cases, and failed to retain computer science basics from school.
Mediocre ones fail to solve problems until some one steps in and does most of their job for them. Average ones are an order of magnitude less productive in terms of lines of code (which is a bad metric) than exceptional ones. Exceptional ones produce more maintainable solutions, make more efficient software, have lower defect rates, defects more likely to be caught by internal diagnostics, and shorter mean times to repair their bugs.
Unfortunately, those things don't show up on resumes so you need to test.
Many technical people fill their resumes with buzz-words but don't actually know what's on there. You need to validate that too.
I ask all interview candidates a few simple coding problems regardless of years of experience. I ask simple data structure questions. I ask for technical details surrounding things they've done. People with surprisingly good back grounds (high GPA at a good school for newer graduates; lots of projects) fail.
One was too offended to continue talking to us; although I'd rather find out that some one is too good and experienced to follow process (bug reporting, coding standards, design cycle) before joining the company.
I worry when I interview at companies which don't check.
I also ask for a reasonably comprehensive code, documentation, and test process walk through.
Although everyone claims they test well but would like to do better and have reasonable software process, most don't and/or have radical variations across the organization depending on what people's background was.
As team lead with staffing control and sufficient resources, you're personally responsible for the project.
Without enough resources, quantifiable partial success (maybe internal use and a few external alpha customers before money runs out) is your duty.
Otherwise, project success is at best something you can influence.
When you're good you'll accomplish notable things (radical performance improvements, patents, the best test environment you've seen with the lowest cost to find and fix bugs, novel external data structures) on almost any project (the notable exception is being stuck with whatever comes up next on the SCRUM burn-down list) and influence co-workers up, down, and side-ways in the org chart so they'll provide positive references.
What happened to an individual project as a whole isn't relevant, although being exposed to both successes (cradle to grave full-life cycle experience) and failures (better to learn from other people's mistakes than to make them first hand when you're responsible) is something to look for in candidates.
400K doesn't buy a studio apartment in a decent location. The least I've seen available for ownership is a one-bedroom apartment for $600K plus HOA fees pushing $400 a month.
In a location with just a few jobs in the Pacific Northwest $400K almost gets you five year old 1500 square foot town house with attached 2-car garage and $200 a month HOA fees.
If you don't want to do build interesting software products you shouldn't be in the business because there are other ways to earn as much money without the huge time sink and stress that comes from how 9 out of 10 projects are run inefficiently with insufficient staffing. Suicidal depression, federal prison, night terrors prior to leaving the business, broken marriages, and similar things are side effects that go with it.
When you do because it's a passion, you might get lucky and be able to kick-start your career in Austin, Boston, Boulder/Denver, Portland, or Seattle but the opportunities there are limited. If you really want to grow you need to work on interesting projects with competent people who've done similar things before and there's only a good selection in the San Francisco Bay Area.
When you aren't content with room mates, $80K isn't a living wage in the Bay Area. Especially in an unstable economy (other places $25-30K in savings will pay your mortgage and even restaurant bills for six months without a pay check). Especially if you plan on reproducing and intend to send your children to a decent school.
When I bought my first 3-bedroom town-house with 600 square feet of basement shop space an attached garage for $160K within walking or cycling distance of anything I wanted in allegedly expensive Boulder CO, $80K was comfortable salary with room for retirement savings, 3 year old used car, and week long annual vacation. Property taxes never went over $1500/year. Income tax maxed out at 4.63 percent.
Properties in comparable Silicon Valley locations with less square footage and no basement are now $800K+ with $8000+ in property taxes (I'd be happy with a 2-bedroom cottage or townhouse with a garage. 3 bedroom ranch homes are still listing for $1.2-$1.4M. The same city names have some low-priced properties, but they go with neighborhoods that have murder rates eclipsing Oakland's and none of the location amenities apart from great tacquerias). Income tax is 9.55% plus a 1.1% state disability surcharge on the first $90K of income.
Even having cashed out near the peak of the market, I could be spending at least $50K a year more on mortgage + taxes to have a comparable life style to someplace purportedly expensive. Mortgage rates are higher now, and it'd probably be a jumbo so that's understating it by a lot. One of my friends from high school bought a house outside St. Louis for half what I spent on my town home so that may not be the right comparison.
As a frame of reference, $150K/year is the cut-off for San Mateo County "moderate income" housing.
This disregards minor incidentals which stem from the high sales taxes and everyone else having to cover the same expenses, like mechanics who charge $25/hour more and beers for twice the price.
That's the immediate situation.
The cost of living and salaries in the first world are over 5X developing countries. The inevitable conclusion is that our salaries and costs of living are going to drop until meeting their rising costs and salaries.
Things aren't worse today only because even with an IQ three sigmas out learning to design and build non-trivial software products takes a ten year apprenticeship with people down the hall who've done comparable scope projects before and learned from their mistakes.
There aren't enough people in developing countries who've done that.
Having travelled and worked with people from all over I don't think those guys are too different from us apart from opportunity. I know people who've learned that you can't mentor people over IM and telephone connections and have headed over seas to get employees at low wages that they can effectively grow. It's an emerging trend. Some companies are paying senior people American wages to live over-seas and build local organizations. Eventually we're going to get enough of that experience over seas to have a collision between their (low) cost of living and required salaries and ours.
I'm working towards owning a home in a low cost, low-tax country before that happens.
You need to have variety in your life both at work and outside work so you don't get burned out on the sameness of it.
Do something productive and quantifiable other than work. I like to build stereo speakers, with other projects being pinball repair, progress towards a private pilots license, etc. Fit an hour or two every day or two into your schedule to make progress - while working 80 hours a week at a startup I finished one pair of speakers and learned enough to fly airplanes without an instructor in the right seat. At 100 hours a week I've spent a small part of the last couple weeks tracking down a malfunction in one of my pinball machines, rebuilding the digital power supplies, and putting in new connectors.
Take a useful development detour and implement something interesting that needs to be done which is different, perhaps which serves as an excuse to learn a new language/tool or revisit one you've gotten crusty in. When one startup was lacking a self-contained product test environment for automation I wrote a Bourne shell script which terminates when any of several descendant processes exit or a timeout fires. In another company I built a model which let us determine how different OEMs hardware would work in our cluster with only a single example and to see how meta-data changes would affect performance; and we shipped the model to OEMs for them to fix hardware bugs without having to deal with our cluster setup.
I take my 4.5 pound laptop into work, xrandr -s 1 and Poof! I have all my files on a large 1920x1080 monitor. I type xrandr -s 0, all my windows move back to the laptop where the files remain. I also have an option for dual displays on the laptop and an external monitor for presentations on a projector. Sneaker net gets my files where they need to go by the time I need them no matter how many gigabytes they consume and how bad local network connectivity is.
Keeping everything important on one backed up (clonezilla, need to rerun) laptop avoids software issues, has single copy update semantics, and exceptional performance (25X faster than NFS at my office, with the tree building in 2 minutes not 50).
Modern laptops are large and fast enough for nearly everything.
>Honorable mention: Implementing a linked list or hash table yourself
In a lot of languages, you're going to implement your own linked lists if you want to have efficient in-order (LIFO or FIFO) and out-of-order removal.
With the C++ STL list template you can stash an iterator in each object and it isn't a problem. WIth Java, Perl, and probably C# that's not an option.
There are fewer situations where an off-the-shelf hash table implementation won't do the trick although they exist.
>Manual multithreading and multitasking
Most programmers can't make systems with multiple interacting locks work right. Thorough testing with contemporary tools is not possible, so customers are often the ones to find problems. For instance, I regularly crashed a SPARC running Solaris to the ROM monitor when doing a simple user space pthreads.
Modeling tools like spin/promela exist to prove locking schemes are correct although locking is often a leaky abstraction and you can't guarantee the implementation tracks the model.
Pre-emptively scheduled kernel threads don't perform and scale well enough for many applications. The C10K paper would be the first popular reference here. Non-premptive user space threads are a partial solution but still have a large cache and TLB footprint.
Consequently, most smart people building reliable and performant systems software end up with message based concurrency control systems. With popular language support (Java, C++, perl, not Erlang or Haskell) lacking appropriate functionality and popular libraries (libevent) being incomplete and not working well in multi-core environments this is usually home brew (Google's kilim might be a good contemporary example). That's manual multi-threading and multi-tasking.
A contemporary definition of "performant" should be on the order of 1M operations per second per node.
>Honorable mention: Non-WYSIWYG editing platforms. Some of us remain comfortable with vi/emacs, command-line compile options or.nroff for documentation formatting, but initially we programmers didn't have a choice.
I'll take vi and a text markup language over WYSIWYG editor any day. Multiple cut buffers make re-arranging text much faster. All of the meta-data is visible with the markup language and can be manipulated with the standard QWERTY keyboard while the WYSIWYG editor doesn't make all of it visible and requires traversing a maze of menus to make sense of it.
With my roff and html resumes I've never had a problem getting bullets at the right indentation level on the first try. With Microsoft Word or Open Office I've had to do little dances with paragraph deletions because traversing the menu structure didn't always do the trick.
This disregards productivity loss due to the temptation to play around with the layout instead of trusting the macro package to do the right thing.
> Honorable mention: Writing your own utilities to search for where you'd used functions or procedures and where you'd called them.
A coding standard makes that painless. Search for ^function( for the definition. Search for white space function( for use. Within a file an editor like vi will jump to the next reference with one key.
For the time I was working on short contracts between interesting full-time positions, I list my employer of record (Drew's Software LLC) instead of the individual companies I contracted with.
Computer languages are analagous to natural languages. In the same way that knowing English isn't enough to make you a novelist or technical writer, knowing C++ isn't enough to be successful at writing non-trivial software that's useful.
I won't even phone screen candidates that don't have practical experience, or don't have at least the level of practical experience I'd expect for some one with their time in industry because people need to be able to design things, keep their thoughts organized, and do it in a way that the software is maintainable. Even the smartest people don't get those things right on their first few attempts. Working open source software (I wrote the original Linux SCSI subsystem and it was bad) or on project classes (in compiler construction we built a compiler that handled some reasonabe subset of 'C') are ways to get that experience without paying jobs.
I won't even bring candidates in for interviews when they don't demonstrate a basic knowledge of algorithmic complexity and data structures since that much is needed to understand why things are thousands (or even millions) of times slower than they should be. An introductory computer science course and data structures are one place to get that. MIT even puts materials on line for their open courseware; that might be the material you want for self-guided study.
In theory you can do things like system administration and testing, although in practice you'll be real limited in those areas and who will hire you. Testing needs to be automated, and the code can be more complex than the software under test. While lots of organizations look down on testers, you really need good software engineers who may just differ from product engineers in the attention span they have (delivering test cases in weeks versus years for some complex products). All competent system administrators do a lot of automation with programming; especially in small organizations where they're likely to wear additional hats as the person automating the build or doing product installation work.
You need a web presence and linkedin is one
on
Linked In Or Out?
·
· Score: 4, Interesting
A web presence connected me with one founder who hired me as first technical employee in his startup (which was fun until we went out of business) and a big corporation with a six figure bonus + relocation package (but no interesting work to go with it).
I get a lot of traffic from recruiters from my linkedin account, some of which I'd entertain if I was looking for a job.
Once you reach the limits of your real-life social network, you really need another marketting strategy for career growth. While not ideal (there's a lot of noise) linkedin is worth the hassle.
Most computer science jobs right out of school involve either debugging some one elses code and adding small enhancements (so I suppose that technically speaking you wouldn't be writing code all day) or testing some one else's code which on a good day means writing automated tests (a task good developers with short attention spans are well suited for) or pushing buttons like a trained monkey.
With some good experience, you'll go through design-implement-debug cycles. If you're creative, write good automated tests which catch bugs early, write robust code, and use tools well you'll spend most of your time writing code. If not you'll spend most of your time debugging.
With more experience, you may spend a significant fraction of your time providing technical leadership so you can get a team to write more code than you could personally. The rewarding things are helping less experienced people grow and getting your work done faster, but it's a lot like actually writing code because you spend a lot of time figuring out how people should be doing what they're trying to do.
You could also detour into project management (once you know how it works) or technical sales support.
If that sort of thing doesn't interest you, you probably want to look at graduating with a different or dual major. It'll be a lot easier now when you have relatively few commitments (no mortgage, children, etc) than later even if you don't get used to the lifestyle that a decent job provides.
>I'd still go with serving coffee at the big company. You'll probably make better contacts at the bigger company, and you'll certainly have a more recognizable name on the resume. It's not what you know but who you know and being able to name-drop.
My experience has been the opposite. I've gotten more jobs and offers based on what I know. The biggest stock (RSU) and option (fraction of the startup) packages were based on that. The best introductions to other people came from small company employees plugged into the startup community because the big company guys mostly just knew people at the same big company.
While I'd rather hire former co-workers who I know to be exceptional, most of them tend to stay happy enough where they are that I can't get enough of them and most of the people I've hired were people I didn't know.
Nearly everybody I've hired got there doing relatively meaty things compared to their years in industry. Undergraduates who do project classes "Built compiler processing a 'C' subset for the VAX with recursive descent parser and various peephole optimizations" won over those who just made it through the required classes. Grad students with interesting development projects "Developed secure distributed storage system" won over those who just measured web traffic. Guys who did non-trivial design work and made changes to software process in their first few jobs won over those who had just fixed bugs or implemented small subsystems. Working at a large company is not a good way to get to do meaty projects until after you've proven yourself with a decade of service.
When I see recognizable names on resumes I worry more than when I don't because big companies survive by not sucking too badly technically compared to their competition. Many developers from big companies just assume that the bugs will get worked out in test (which will be handled by some one else) or beta (where your company's survival depends on not killing the friendly beta customers this is not good). Even if you're not concerned about financial success those attitudes aren't conducive to an environment where you won't be wasting your time figuring out what stupid things your coworkers did to break things that you have to cleanup to make progress on your work. I personally made the mistake of trying working for two big companies because I thought that if local startups weren't getting funded maybe I could do a cool project in a big company. There I found that things were at least as bad as I thought from the outside. One group produced software so poorly tested that there were nights I got paged hourly from midnight on when the software malfunctioned.
Find a free software project or concept you like and contribute. It'll be the worst software you write in your career but you'll learn about what makes software more or less maintainable without doing that on an employer's dime.
Take project classes from a local university. I've interviewed a lot of candidates who graduated with high grade point averages and an ocassional master's degree but limited problem solving and programming skills, but few of them had any project classes like compiler construction where you build a toy 'C' or whatever compiler (a lot of these are group projects, so at least one member of the team can get away with slacking).
Write automated tests. Getting testing right can be more complicated than the code.
Volunteer to write tools at your current job. There are always more things that need doing than people to do them, especially now that hiring has been cut back.
>Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this?
>Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
If all your problems are sufficiently similar, it will be a time saver. This will be the case if your company just builds device drivers for one operating system or does electronic store fronts that are all the same apart from the graphics.
For the broad spectrum of components that go into even a single product (a hypothetical digital video product for the broadcast market might have a high performance real-time system which does zero copy from network to disk and a web GUI) you'll do a lot better with tools that are appropriate for the job. You don't want to do zero copy IO with hard real time constraints of tens of milliseconds in Java. You don't want to do the web front end in 'C' regardless of what library you put on top of it. No popular language+platform covers those two bases acceptably well to say nothing of text processing, distributed systems, ad-hoc query processing...
When you have to use the wrong tools for the job, really good people will use those tools to build better tools which are suited to solving the problem sooner with solutions more likely to be correct and performant. Less experienced or less talented people will just expend more effort trying to pound square pegs into round holes. In both cases where an appropriate tool exists you'll be better off just using it.
I'd suggest you tell management that provided you have developers who know the programming paradigm (functional, object oriented, etc.); know one language in the Algol family tree; and know a good scripting/text processing tool set you're going to loose less time to spinup than using the wrong tool and start looking for a job in case that doesn't work, because
1) in most cases tool and language constraints are going to be both unpleasant and cause productivity (and therefore profit margins) to suffer.
2) management making decisions based on thinking they know more about technical subjects than the technical staff is not a good sign.
Slashdot Mirror
While languages are easy, transitioning from language controlled resource management (as in languages with garbage collected language memory management) to programmer controlled (as in languages with garbage collected memory management that do nothing with other resources like file descriptors) is harder.
I've seen situations where "java programmer" graduates meet the real world with file descriptor leaks that bring down "enterprise" systems resulting in customer outages with pagers going off, and would much rather have ones used to dealing with their own resource management.
In an ideal world the language people would have used reference counting, but we don't live in an ideal world.
And for your information, a workhorse can't read specs, and a programmer without passion for his job will not follow them.
Programmers without passion often follow the specs to keep their jobs but don't exert effort to correct incorrect specs.
Private offices are far less expensive than the cost to productivity from open office environments.
1. IBM Research studied the problem, and found that engineers are 40% more productive in quiet private offices than open environments. At a fully burdened annual cost of $100-$200K per engineer open seating could cost you $120,000-$240,000 a year.
2. It can take fifteen minutes to enter a mental 'flow' state. Once you get a high enough interrupt rate it's difficult to get anything done until people go home for the day.
3. Open offices encourage unnecessary communication. Where people might find answers themselves they ask their co-workers because it's easy thus saving minutes for themselves at the cost of up to fifteen minutes from their co-workers.
>Clearly, very few people here have any enterprise-level Solaris experience. In terms of stability and performance I compare Linux to Solaris like you compare Windows to Linux.
I used Solaris in a cellular base station billing interface appliance.
Moderate thread use crashed it out to the ROM monitor (we gained usable stability and a 100X performance improvement by switching to an event driven scheme) and sequential performance through the file system was half that of Linux (it was good enough for our use).
You can pick anecdotal stories to support any hypothesis regarding operating system stability you want.
1. Contribute to a free software project which interests you.
This will allow potential employers to verify that you can program before bringing you in for an interview, and hopefully you'll learn something about writing maintainable code so your first paying employer doesn't bear the burden of getting you over those hurdles.
2. Network.
Maybe a local group of geeks gather weekly for beer. Maybe there's an interesting user's group. Meeting people at such groups make access to un-advertised positions or to some one in engineering (not HR) that can be intelligent about who to bring in for interviews.
The typical Microsoft/Eclipse/whatever GUI today is horribly wasteful: vast areas are wasted on window dressing, toolbars, menus, scrollbars...
I get around that by not using an IDE except to debug Java I've written. In vim each source file, build error log, or document is separated by one character whether they're arranged side by side or vertically and there's no scroll bar or mouse needed. For compiled languages the debugger gets one window with a couple pixels around it plus a scroll bar with watch expression display together with source.
If an emacs user taunted me about running my debuggers in a separate window I might be tempted to get the Conque plugin.
Any arbitrary limit on line width belongs in another century, and IME just results in developers who have a good reason to write a relatively long line messing around with awkward formatting hacks or truncating identifiers in order to obey the letter of the law.
While an arbitrary limit is bad, there's a point at which running into a limit generally means that indentation levels are getting too deep because function granularity is too coarse. You months or years later, your co-workers, and successors will all be happier if you fix the problem instead of trying to squeeze things into the 'letter of the law'. With name spaces and APIs having POSIX-length identifiers 80 characters is appropriate. 120 characters works for longer things.
A one-page function length limit with occasional exceptions is also a fine idea.
1. Professional organizations can offer affordable group plans to their members. One example is the Microsoft Alumni Network open to all former Microsoft employees. IIRC, their small business group plan was open to companies with 2 or more total employees which could be you and your spouse (paid to file your taxes or whatever).
2. Your single employee business can outsource its benefits to a PEO (Professional Employer Organization), some of which have no minimum company size.
Both options get you into large groups which therefore have relatively good rates for group plans, which is to say very expensive for young healthy people but relatively affordable for the rest of us.
Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).
You might get within an order of magnitude (days, weeks, months, years) without the low level design.
A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.
And an even smaller multiplier (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.)
Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.
An experienced unix user would use man -k
drew@l-drew% man -k burn
k3b (rpm) - CD/DVD burning application for KDE
nautilus-cd-burner (rpm) - Easy to use CD burning for Gnome
Unfortunately, the yutzes putting together Linux distributions (this is Centos) don't always include the man pages:
drew@l-drew% which k3b /usr/bin/k3b /usr/bin/nautilus-cd-burner
drew@l-drew% man k3b
No manual entry for k3b
drew@l-drew%
drew@l-drew% man nautilus-cd-burner
No manual entry for nautilus-cd-burner
Most "software engineers" can't solve simple problems in a reasonable time frame, don't check corner cases, and failed to retain computer science
basics from school.
Mediocre ones fail to solve problems until some one steps in and does most of their job for them. Average ones are an order of magnitude less productive in terms of lines of code (which is a bad metric) than exceptional ones. Exceptional ones produce more maintainable solutions, make more efficient software, have lower defect rates, defects more likely to be caught by internal diagnostics, and shorter mean times to repair their bugs.
Unfortunately, those things don't show up on resumes so you need to test.
Many technical people fill their resumes with buzz-words but don't actually know what's on there. You need to validate that too.
I ask all interview candidates a few simple coding problems regardless of years of experience. I ask simple data structure questions. I ask for technical details surrounding things they've done. People with surprisingly good back grounds (high GPA at a good school for newer graduates; lots of projects) fail.
One was too offended to continue talking to us; although I'd rather find out that some one is too good and experienced to follow process (bug reporting, coding standards, design cycle) before joining the company.
I worry when I interview at companies which don't check.
I also ask for a reasonably comprehensive code, documentation, and test process walk through.
Although everyone claims they test well but would like to do better and have reasonable software process, most don't and/or have radical variations across the organization depending on what people's background was.
As team lead with staffing control and sufficient resources, you're personally responsible for the project.
Without enough resources, quantifiable partial success (maybe internal use and a few external alpha customers before money runs out) is your duty.
Otherwise, project success is at best something you can influence.
When you're good you'll accomplish notable things (radical performance improvements, patents, the best test environment you've seen with the lowest cost to find and fix bugs, novel external data structures) on almost any project (the notable exception is being stuck with whatever comes up next on the SCRUM burn-down list) and influence co-workers up, down, and side-ways in the org chart so they'll provide positive references.
What happened to an individual project as a whole isn't relevant, although being exposed to both successes (cradle to grave full-life cycle experience) and failures (better to learn from other people's mistakes than to make them first hand when you're responsible) is something to look for in candidates.
400K doesn't buy a studio apartment in a decent location. The least I've seen available for ownership is a one-bedroom apartment for $600K plus HOA fees pushing $400 a month.
In a location with just a few jobs in the Pacific Northwest $400K almost gets you five year old 1500 square foot town house with attached 2-car garage and $200 a month HOA fees.
If you don't want to do build interesting software products you shouldn't be in the business because there are other ways to earn as much money without the huge time sink and stress that comes from how 9 out of 10 projects are run inefficiently with insufficient staffing. Suicidal depression, federal prison, night terrors prior to leaving the business, broken marriages, and similar things are side effects that go with it.
When you do because it's a passion, you might get lucky and be able to kick-start your career in Austin, Boston, Boulder/Denver, Portland, or Seattle but the opportunities there are limited. If you really want to grow you need to work on interesting projects with competent people who've done similar things before and there's only a good selection in the San Francisco Bay Area.
When you aren't content with room mates, $80K isn't a living wage in the Bay Area. Especially in an unstable economy (other places $25-30K in savings will pay your mortgage and even restaurant bills for six months without a pay check). Especially if you plan on reproducing and intend to send your children to a decent school.
When I bought my first 3-bedroom town-house with 600 square feet of basement shop space an attached garage for $160K within walking or cycling distance of anything I wanted in allegedly expensive Boulder CO, $80K was comfortable salary with room for retirement savings, 3 year old used car, and week long annual vacation. Property taxes never went over $1500/year. Income tax maxed out at 4.63 percent.
Properties in comparable Silicon Valley locations with less square footage and no basement are now $800K+ with $8000+ in property taxes (I'd be happy with a 2-bedroom cottage or townhouse with a garage. 3 bedroom ranch homes are still listing for $1.2-$1.4M. The same city names have some low-priced properties, but they go with neighborhoods that have murder rates eclipsing Oakland's and none of the location amenities apart from great tacquerias). Income tax is 9.55% plus a 1.1% state disability surcharge on the first $90K of income.
Even having cashed out near the peak of the market, I could be spending at least $50K a year more on mortgage + taxes to have a comparable life style to someplace purportedly expensive. Mortgage rates are higher now, and it'd probably be a jumbo so that's understating it by a lot. One of my friends from high school bought a house outside St. Louis for half what I spent on my town home so that may not be the right comparison.
As a frame of reference, $150K/year is the cut-off for San Mateo County "moderate income" housing.
This disregards minor incidentals which stem from the high sales taxes and everyone else having to cover the same expenses, like mechanics who charge $25/hour more and beers for twice the price.
That's the immediate situation.
The cost of living and salaries in the first world are over 5X developing countries. The inevitable conclusion is that our salaries and costs of living are going to drop until meeting their rising costs and salaries.
Things aren't worse today only because even with an IQ three sigmas out learning to design and build non-trivial software products takes a ten year apprenticeship with people down the hall who've done comparable scope projects before and learned from their mistakes.
There aren't enough people in developing countries who've done that.
Having travelled and worked with people from all over I don't think those guys are too different from us apart from opportunity. I know people who've learned that you can't mentor people over IM and telephone connections and have headed over seas to get employees at low wages that they can effectively grow. It's an emerging trend. Some companies are paying senior people American wages to live over-seas and build local organizations. Eventually we're going to get enough of that experience over seas to have a collision between their (low) cost of living and required salaries and ours.
I'm working towards owning a home in a low cost, low-tax country before that happens.
You need to have variety in your life both at work and outside work so you don't get burned out on the sameness of it.
Do something productive and quantifiable other than work. I like to build stereo speakers, with other projects being pinball repair, progress towards a private pilots license, etc. Fit an hour or two every day or two into your schedule to make progress - while working 80 hours a week at a startup I finished one pair of speakers and learned enough to fly airplanes without an instructor in the right seat. At 100 hours a week I've spent a small part of the last couple weeks tracking down a malfunction in one of my pinball machines, rebuilding the digital power supplies, and putting in new connectors.
Take a useful development detour and implement something interesting that needs to be done which is different, perhaps which serves as an excuse to learn a new language/tool or revisit one you've gotten crusty in. When one startup was lacking a self-contained product test environment for automation I wrote a Bourne shell script which terminates when any of several descendant processes exit or a timeout fires. In another company I built a model which let us determine how different OEMs hardware would work in our cluster with only a single example and to see how meta-data changes would affect performance; and we shipped the model to OEMs for them to fix hardware bugs without having to deal with our cluster setup.
I take my 4.5 pound laptop into work, xrandr -s 1 and Poof! I have all my files on a large 1920x1080 monitor. I type xrandr -s 0, all my windows move back to the laptop where the files remain. I also have an option for dual displays on the laptop and an external monitor for presentations on a projector. Sneaker net gets my files where they need to go by the time I need them no matter how many gigabytes they consume and how bad local network connectivity is.
Keeping everything important on one backed up (clonezilla, need to rerun) laptop avoids software issues, has single copy update semantics, and exceptional performance (25X faster than NFS at my office, with the tree building in 2 minutes not 50).
Modern laptops are large and fast enough for nearly everything.
>Honorable mention: Implementing a linked list or hash table yourself
In a lot of languages, you're going to implement your own linked lists if you want to have efficient in-order (LIFO or FIFO) and out-of-order removal.
With the C++ STL list template you can stash an iterator in each object and it isn't a problem. WIth Java, Perl, and probably C# that's not an option.
There are fewer situations where an off-the-shelf hash table implementation won't do the trick although they exist.
>Manual multithreading and multitasking
Most programmers can't make systems with multiple interacting locks work right. Thorough testing with contemporary tools is not possible, so customers are often the ones to find problems. For instance, I regularly crashed a SPARC running Solaris to the ROM monitor when doing a simple user space pthreads.
Modeling tools like spin/promela exist to prove locking schemes are correct although locking is often a leaky abstraction and you can't guarantee the implementation tracks the model.
Pre-emptively scheduled kernel threads don't perform and scale well enough for many applications. The C10K paper would be the first popular reference here. Non-premptive user space threads are a partial solution but still have a large cache and TLB footprint.
Consequently, most smart people building reliable and performant systems software end up with message based concurrency control systems. With popular language support (Java, C++, perl, not Erlang or Haskell) lacking appropriate functionality and popular libraries (libevent) being incomplete and not working well in multi-core environments this is usually home brew (Google's kilim might be a good contemporary example). That's manual multi-threading and multi-tasking.
A contemporary definition of "performant" should be on the order of 1M operations per second per node.
>Honorable mention: Non-WYSIWYG editing platforms. Some of us remain comfortable with vi/emacs, command-line compile options or .nroff for documentation formatting, but initially we programmers didn't have a choice.
I'll take vi and a text markup language over WYSIWYG editor any day. Multiple cut buffers make re-arranging text much faster. All of the meta-data is visible with the markup language and can be manipulated with the standard QWERTY keyboard while the WYSIWYG editor doesn't make all of it visible and requires traversing a maze of menus to make sense of it.
With my roff and html resumes I've never had a problem getting bullets at the right indentation level on the first try. With Microsoft Word or Open Office I've had to do little dances with paragraph deletions because traversing the menu structure didn't always do the trick.
This disregards productivity loss due to the temptation to play around with the layout instead of trusting the macro package to do the right thing.
> Honorable mention: Writing your own utilities to search for where you'd used functions or procedures and where you'd called them.
A coding standard makes that painless. Search for ^function( for the definition. Search for white space function( for use. Within a file an editor like vi will jump to the next reference with one key.
For the time I was working on short contracts between interesting full-time positions, I list my employer of record (Drew's Software LLC) instead of the individual companies I contracted with.
Computer languages are analagous to natural languages. In the same way that knowing English isn't enough to make you a novelist or technical writer, knowing C++ isn't enough to be successful at writing non-trivial software that's useful.
I won't even phone screen candidates that don't have practical experience, or don't have at least the level of practical experience I'd expect for some one with their time in industry because people need to be able to design things, keep their thoughts organized, and do it in a way that the software is maintainable. Even the smartest people don't get those things right on their first few attempts. Working open source software (I wrote the original Linux SCSI subsystem and it was bad) or on project classes (in compiler construction we built a compiler that handled some reasonabe subset of 'C') are ways to get that experience without paying jobs.
I won't even bring candidates in for interviews when they don't demonstrate a basic knowledge of algorithmic complexity and data structures since that much is needed to understand why things are thousands (or even millions) of times slower than they should be. An introductory computer science course and data structures are one place to get that. MIT even puts materials on line for their open courseware; that might be the material you want for self-guided study.
In theory you can do things like system administration and testing, although in practice you'll be real limited in those areas and who will hire you. Testing needs to be automated, and the code can be more complex than the software under test. While lots of organizations look down on testers, you really need good software engineers who may just differ from product engineers in the attention span they have (delivering test cases in weeks versus years for some complex products). All competent system administrators do a lot of automation with programming; especially in small organizations where they're likely to wear additional hats as the person automating the build or doing product installation work.
A web presence connected me with one founder who hired me as first technical employee in his startup (which was fun until we went out of business) and a big corporation with a six figure bonus + relocation package (but no interesting work to go with it).
I get a lot of traffic from recruiters from my linkedin account, some of which I'd entertain if I was looking for a job.
Once you reach the limits of your real-life social network, you really need another marketting strategy for career growth. While not ideal (there's a lot of noise) linkedin is worth the hassle.
Most computer science jobs right out of school involve either debugging some one elses code and adding small enhancements (so I suppose that technically speaking you wouldn't be writing code all day) or testing some one else's code which on a good day means writing automated tests (a task good developers with short attention spans are well suited for) or pushing buttons like a trained monkey.
With some good experience, you'll go through design-implement-debug cycles. If you're creative, write good automated tests which catch bugs early, write robust code, and use tools well you'll spend most of your time writing code. If not you'll spend most of your time debugging.
With more experience, you may spend a significant fraction of your time providing technical leadership so you can get a team to write more code than you could personally. The rewarding things are helping less experienced people grow and getting your work done faster, but it's a lot like actually writing code because you spend a lot of time figuring out how people should be doing what they're trying to do.
You could also detour into project management (once you know how it works) or technical sales support.
If that sort of thing doesn't interest you, you probably want to look at graduating with a different or dual major. It'll be a lot easier now when you have relatively few commitments (no mortgage, children, etc) than later even if you don't get used to the lifestyle that a decent job provides.
>I'd still go with serving coffee at the big company. You'll probably make better contacts at the bigger company, and you'll certainly have a more recognizable name on the resume. It's not what you know but who you know and being able to name-drop.
My experience has been the opposite. I've gotten more jobs and offers based on what I know. The biggest stock (RSU) and option (fraction of the startup) packages were based on that. The best introductions to other people came from small company employees plugged into the startup community because the big company guys mostly just knew people at the same big company.
While I'd rather hire former co-workers who I know to be exceptional, most of them tend to stay happy enough where they are that I can't get enough of them and most of the people I've hired were people I didn't know.
Nearly everybody I've hired got there doing relatively meaty things compared to their years in industry. Undergraduates who do project classes "Built compiler processing a 'C' subset for the VAX with recursive descent parser and various peephole optimizations" won over those who just made it through the required classes. Grad students with interesting development projects "Developed secure distributed storage system" won over those who just measured web traffic. Guys who did non-trivial design work and made changes to software process in their first few jobs won over those who had just fixed bugs or implemented small subsystems. Working at a large company is not a good way to get to do meaty projects until after you've proven yourself with a decade of service.
When I see recognizable names on resumes I worry more than when I don't because big companies survive by not sucking too badly technically compared to their competition. Many developers from big companies just assume that the bugs will get worked out in test (which will be handled by some one else) or beta (where your company's survival depends on not killing the friendly beta customers this is not good). Even if you're not concerned about financial success those attitudes aren't conducive to an environment where you won't be wasting your time figuring out what stupid things your coworkers did to break things that you have to cleanup to make progress on your work. I personally made the mistake of trying working for two big companies because I thought that if local startups weren't getting funded maybe I could do a cool project in a big company. There I found that things were at least as bad as I thought from the outside. One group produced software so poorly tested that there were nights I got paged hourly from midnight on when the software malfunctioned.
With a reasonable coding standard, it's easier to say :,/^}/s/foo/bar/g
to get replacements to the end of the function.
You need to actually write software.
Find a free software project or concept you like and contribute. It'll be the worst software you write in your career but you'll learn about what makes software more or less maintainable without doing that on an employer's dime.
Take project classes from a local university. I've interviewed a lot of candidates who graduated with high grade point averages and an ocassional master's degree but limited problem solving and programming skills, but few of them had any project classes like compiler construction where you build a toy 'C' or whatever compiler (a lot of these are group projects, so at least one member of the team can get away with slacking).
Write automated tests. Getting testing right can be more complicated than the code.
Volunteer to write tools at your current job. There are always more things that need doing than people to do them, especially now that hiring has been cut back.
>Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this?
>Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"
If all your problems are sufficiently similar, it will be a time saver. This will be the case if your company just builds device drivers for one operating system or does electronic store fronts that are all the same apart from the graphics.
For the broad spectrum of components that go into even a single product (a hypothetical digital video product for the broadcast market might have a high performance real-time system which does zero copy from network to disk and a web GUI) you'll do a lot better with tools that are appropriate for the job. You don't want to do zero copy IO with hard real time constraints of tens of milliseconds in Java. You don't want to do the web front end in 'C' regardless of what library you put on top of it. No popular language+platform covers those two bases acceptably well to say nothing of text processing, distributed systems, ad-hoc query processing...
When you have to use the wrong tools for the job, really good people will use those tools to build better tools which are suited to solving the problem sooner with solutions more likely to be correct and performant. Less experienced or less talented people will just expend more effort trying to pound square pegs into round holes. In both cases where an appropriate tool exists you'll be better off just using it.
I'd suggest you tell management that provided you have developers who know the programming paradigm (functional, object oriented, etc.); know one language in the Algol family tree; and know a good scripting/text processing tool set you're going to loose less time to spinup than using the wrong tool and start looking for a job in case that doesn't work, because
1) in most cases tool and language constraints are going to be both unpleasant and cause productivity (and therefore profit margins) to suffer.
2) management making decisions based on thinking they know more about technical subjects than the technical staff is not a good sign.