Link to Original Source
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Link to Original Source
I feel this way about the current codebase I'm working on right now, but they only give me the nerf-type of weapons, so no one needs to worry.
What would your programming language look like if the Pointy-Haired Boss had to be able to understand it?
Ruby and Cucumber (at least for your test code)?
I don't really care about being able to fly (As I don't know or want to know how to do that anyway), shrink, go subterranean, or any other ridiculous thing. I'd settle for the following in a perfect vehicle:
- Run on a clean, cheap, limitless (or nearly so) fuel source.
- Be able to carry as much cargo as I need to when I need it, but be compact and maneuverable when I don't.
- Self-repair itself. If I didn't have to go to another mechanic for the rest of my life I would be perfectly happy.
- Actually be safe, with zero chance of injury to passengers.
In my opinion these are way more important than the bunk listed in the options Can you imagine all the idiots on the road today, except that every single one of them can potentially smash your house flat from the sky?
It's possible I've used the wrong word here, but when I talk about being passionate about your job I'm not talking about being "emotional" about your job.
What I'm talking about is going above and beyond the minimum required effort. The absolute minimum required effort is usually that the software works, it satisfies the client's requirements, it comes in under or at budget (this is obviously more at the project level and then individual developer level), and that it can be maintained. Above and beyond is about craftsmanship. It is about TDD, refactoring until you have made your best effort to get the code clean, and pushing back on ridiculous requirement to get to the true business need. It's about taking the time to learn new technologies off the clock, it's about giving back to the community that has given you so much (Do you, for even one moment, imagine that you got where you are because you learned and worked in a vaccum?). Whether this giving back mean you contribute to open source project, you maintain a blog, attend or present at user group meetings, etc is up to you, but if you're going to work with me I want to see that you're active and you give a shit.
don't think that I care more about your projects than my family or my personal obligations
As a family man myself I completely understand your sentiment. There is certainly a balance to be held. I spend time with my family and love my children, but I also know that nobody, noboby owes me a free ride and it is up to me to excel and continue to learn and grow as a developer outside of the 9-5. Clients almost never pay me to learn on their dime, and when I talk about being passionate I'm talking about understanding that you need to give enough of a shit to grow on your own and give back. I want to work with developers who are on that wave length and do more than clock in, write their 500 LOC/day, clock out and promptly forget about programming until 9AM the next day.
No problem, it is always nice to have a good conversation, not to mention being pleasantly surprised by a thoughtful and polite AC
Not with an attitude like that we're not.
If you're in it purely for the money you're in it for purely the wrong reason. Passion is is not stupid, or a sign of weakness. Passion is caring about the work that you do, and therefore about the work that others do because ultimately their work is what matters. IT is not an end unto itself, it is a means to accomplish other things. Being passionate shows you care about the quality of your work and the quality of others' work. If you come to the table and you can't show passion about your work and your overriding value is money then hit the road. There are thousands of others just like you who would love the chance to show they can do the job, and they may or may not charge your rate.
if my best code I've written is proprietary, how can I show that to you?
This is why I look for recommendations and blog posts. I'm in the same boat that you're in, which is that my best code is proprietary. The solutions is to have others recommend your work and by writing about the things you learn. By this I don't mean that you post specifics about your code as it is the implementation of the concept or technique you have learned (not to mention posting chunks of proprietary code will get you fired or sued). It isn't the specific code that matters, it is showing that you have the skills, knowledge, ability to learn and care enough to share these things for the benefit of others.
Makes me be the question: you want someone who just puts stuff online to show off, or do you want someone with a track record of getting the job done?
So first of all you're looking at this the wrong way. You're not "showing off" per se. You're selling your services in most honest manner you can. You have to get over the idea that you shouldn't talk about yourself. You're in business, and in business no one will sell for you. You have to be your own champion, and that means being willing to put yourself out there, talk about what you've learned and show people why they should hire you.
To answer you question "getting the job done" is obviously the important thing. The trick is showing people who have no idea who you are or what you've done that you can, in fact, get the job done. When they are interviewing you they are trying to determine if it is a "safe bet" to hire you on, and make no mistake it is a bet. Chances are neither they nor you will know if it is a good fit until after the fact, but you can help them make that decision and put them somewhat at ease by talking about yourself and sharing your experience ahead of the conversation.
My job as the technical interviewer is to determine if the things you say you know and have done matches up to reality. You'll make my job easier if you can show me that concretely, and therefore make it more likely that I'll recommend you to continue in the hiring process.
I pay scant attention to resumes, except as a starting point and a way to see if you can string words together in a syntactically correct manner. Not having an online presence won't hurt you necessarily. After the receiving a resume the first thing I'll do is to google you to see if you have:
- Public code contributions (Github, BitBucket, SourceForge, Launchpad, etc). This is probably the most important bullet on this list. I want to see that you're passionate about software development, and that you're taking the time to grow and learn outside of your day job.
- Any kind of technical blog. I don't care about your blog about your love of spaghetti, I want to see if you are capable of communicating technical ideas, and more importantly that you see the value of sharing your knowledge with others. I'm not interested in working with introverts or knowledge hoarders, I want to work with people who are interested in building others up, making an impact on the lives of others, and helping other developers to grow.
- Recommendations on LinkedIn. I don't care about endorsements; they're essentially worthless as the endorser doesn't need to put any thought into the skill being endorsed and how well the individual actually performed that skill. They simply click the endorse button and move on. Recommendations are different as they require some thought on the part of the recommender and show that the work that you did actually mattered to someone. It also also fairly easy to weed out the true recommendations from the "cookie-cutter" recommendations.
- A low profile on Facebook, or failing that a "clean" public profile. Twitter is fine, with the same caveat that the profile is clean. Technologists who don't know how to manage their public interactions make me wonder how they manage their professional interactions.
I use this information to prepare for the technical interview, and make notes to call you out on your experience and listed skills. If you walk the walk it will show through in your online presence, face-to-face and pairing interview.
Not having these things is not necessarily a bad thing, especially if you're fresh out of college, but having them lets you tell your story. Not to mention that if you have any length of experience I'd be suspicious if you didn't engage in at least some of these activities.
Non-critical doesn't mean trivial or unimportant. Simply because he doesn't see the changes at the same level of criticality (is that a word?) doesn't mean that they're not important to someone. The message he sent out on the mailing list goes on to say:
Anyway, the rc5 changes are pretty much all over: pretty much exactly half are drivers (networking, usb, gpu, mmc, sound..), with the other half being various other subsystems. Some arch updates: MIPS, arm, smattering of ia64, microblaze, s390 and some x86. And networking (non-driver), xfs, fuse, gfs2, jfs..
I don't know about you, but none of those things sound unimportant to me. How long have people been bitching about driver and network support in the kernel? And he's complaining that that stuff is getting fixed? Please. The fact of the matter is that he's annoyed because he refuses the let got of the reins and let someone else help out. If he is the gatekeeper than this is what he should expect.
So, the great thing about an Open Source project is that developers have the ability to say "Hey, I think we can do this better." and then go off and actually fix it. They are not beholden to a corporate IT overlord that says "Thou shalt not commit code that is directly related with the task in front of you!" Telling a contributor that they shouldn't be submitting the code they worked on is a great way to kill creativity and drive people away from the project.
As far as Torvalds getting pissed off (as a feint or not) and talking smack about how when a developer's mother sat round the house she sat around the house he's brought this on himself as the gatekeeper for the project. This is simply the nature of an Open Source project. Furthermore there is nothing that says he can't simply reject a pull request and declare the RC closed for anything but direct bug fixes (which is what he is actually doing I suppose).
FWIW I don't disagree with you exactly, I just think it is important to keep in mind what kind of project and what kind of developers we're talking about.
Everyone has to have a hobby, right?
Seriously though, who the hell cares if the RC is bigger than the one before it, or whether the changes are scattered everywhere? If there were any number of concerns that needed to be addressed before the next release then it wasn't ready to go in the first place. Just test the hell out of everything, make sure nothing is broken, and make sure that each change was necessary and correct. In short calm your tits and keep coding.