RSS"Java is slow." "Windows always crashes." "We have to do it this way; it's the way we've always done it!"
As we grow at work, I find the rules of thumb that I usually follow and ask others to do the same have become carved in stone. Those who don't fully understand "why" they're doing it have taken it as immutable doctrine. When I ask for minor deviations in these rules of thumb, I'm met with resistance! My own words are fighting against me!
Years ago, when I also wore the "build master" hat, I would put a cut of our weekly release to server #13 for QA to smoke test. Thirteen is a lucky number for me. Eventually we hired some poor soul who now does our builds. They still smoke test on server #13 every week.
When I suggested the other week that they rotate which server smoke testing is done on (as we've got a fair number now), I was met with "but we *always* test on #13! We have to test on that server!" QA wasn't quite sure why though.
Technological mythology forms when people are dealing with a complexity they don't understand. It forms easily, spreads like wildfire through all kinds of mediums (email, wikis, conference calls) and is hard to combat. Education doesn't work. It can be more painful to untangle than your CIO's SOA plans..
Cutting Through "Technological Mythology"
Tips on Getting Your Development Co-Op Job
As a co-op student, you likely get a lot of advice from academics on things - that in 10 years - you will do intuitively as tying your shoe and checking for unprotected wifi networks. Here are some tips from The Real World that you should double-check before applying to your co-op position.
Nobody is expecting you to be a master of the things you list. They'll expect you to be proficient in them enough to not be stumbling with the basic concepts behind them. That's okay, if you are a rock star, they'll be blown away.
Your Resume
1) List specific bits of technology you know. It doesn't matter if you used it in school, on an assignment, your last co-op term or at home.
- If you've used a flavour of Linux, say which flavours.
- List versions too, but list them as a range (PHP 3-5, Java 1.3-5.0, Fedora Core 2+).
- List languages you've written anything substantial in. Ask yourself "Is this something with a bit of spit and polish could be an open source project?", if so, it's substantial.
- Include IDEs that you could create, debug and maintain a program with at least 10+ classes in (MSVC, Emacs, Eclipse, NetBeans, IntelliJ, etc..). Don't include the version of the IDE.
- If you've used a source control system, list those too. Any system where you could checkout a project, synchronize your local copy and commit changes to counts. (CVS, SVN, etc..).
- Same with any build tools you've used. If you're proficient enough to copy an existing build script you have to mold it to a new project, then it counts. Make sure you know the versions of the tools, but don't include them on your resume.
- Any frameworks or toolkit-like libraries you've used: Spring, Swing, Struts, Hibernate, OpenGL, StAX, JMS, etc.
- Any "application running servery things". Applications like Apache, IIS, JBoss, WebSphere, etc.. Include which versions you know.
- List databases you know how to connect a client to, list which tables are available, select some data from a table and do a simple update. If you can't do this, don't list databases.
- Describe it as if you're explaining it to a total stranger.
- What tools/languages/frameworks did you use?
- Compared to the people who were in your group, what did you do?
- What was the hardest part?
- Projects you've done outside of school are where you'll shine. These will show a genuine interest in computer science and will set you apart from everyone else.
- Nobody technical will seriously read your cover letter. Geeks like reading them as much as geeks like writing them.
- Personalize your cover letter. Spend ten minutes to read about the company you're applying to and make reference to it in your cover letter.
- If you mention technology in your cover letter that's not in your resume, then add it to your resume.
- Your cover letter should demonstrate your "excellent communication skills". Grammar, spelling, word selection, pacing, etc are all important. If you don't have excellent communication skills, then just don't make that claim.
- Spell check. Proofread.
1) Prepare before your interview.
- Be prepared to have a project you worked on in mind to discuss. If you're asked to cite a project, use that one.
- Know a wee bit about the company, go through their website, read about their products. It will make it easier for you to understand the view of the company the interviewer will have.
- If you're asked to provide availability for an interview, give a few different times. You won't seem eager if you say "I understand people are busy with meetings during the day, therefore I want to provide you with a few times I'm available." Or more simply "every day from 2:00 to 3:00 I have a break in my classes. Just give me one day's notice."
- If in person, be on time. If on the phone, use a land line, not a cell phone.
- Tell the interviewer you want to talk about your above selected project if you accidentally find yourself talking about a different one during the interview. I'm not kidding. Just say "I enjoyed that project, but this other project is more interesting to discuss." The interviewer will love you.
- If you feel there's an aspect about your skills or knowledge that you shine in that the interviewer has missed and is relevant to the position, ask to talk about it at the end of the interview. "While we didn't touch on it directly, I understand security is an important aspect of your product. I've integrated a PKI system into my last project, and previously wrapped my IRC bot's command interface in an SSL tunnel."
- Be polite and be relaxed. Remember the person across from you is a real person too, not a superhuman.
- If you're asked a question and you don't know the answer, feel free to ask about it. As a student, you're used to asking about new things. Don't ask about *everything* though. If you have an insightful analysis about what you've just learned, make a comment on it.
- Have a few questions prepared and memorized. Be able to ask them naturally. Good questions you probably want to know include "What is the development environment like?", "What do you envision someone in my position to be doing?", "How long is a lifecycle for this product? Will my term be long enough to see my work into fruition?"
- If you know you messed up on any questions, do some research on where you made mistakes and what the correct answers are.
- By the time you send a Thank You email, they will have likely made a decision. That said, if your Thank You letter is timely and relevant, it's a nice gesture. Also, if they were on the fence about you, it will sway them; especially if you make mention about the research you did after the interview.
Dog Food Not Enough for CI Servers
Our Continuum CI server constantly had problems hanging during builds, so we switched to Bamboo, which while not perfect, is better.
This week our Bamboo server ate its own config file when it ran out of disk space and this got me thinking that most CI servers I've seen these days do a horrible job at handling the plethora of near-failure conditions that plague a build.
What's really needed is a maven plugin that acts like a semi-broken build (hold your jokes) so the CI guys can test how well their code handles failures.
This plugin should have at least four different operating modes:
1. Disk hog: Write huge files in the workspace, filling up the disk if possible.
2. Memory hog: Consume huge chunks of memory until it OOMs.
3. CPU hog: Spawn a bunch of threads that grind the CPU to a halt.
4. Hung thread: Get a thread to ignore all signals to it and let it hang.
If the CI server can monitor and recover from these four common semi-broken build issues, then it's quite possibly worth its salt. Otherwise it's really just a pricey/fancy wrapper with what could otherwise be a 3 line shell script piped to mail(1).
