Over the years one of the things that I’ve seen missing in disproportionate amounts are many opportunities for part time work in the software development industry. There are two things about this fact that makes me kind of chuckle at the absurdity behind them.
Much of the time there isn’t any part time work because so much of management and the existing group think is that more hours equal more productivity and more product. This is, however, very wrong.
If software developers did work fewer hours, they actually have a high possibility that they’d become more productive, not less.
Shock, gasp, horror, no, tell me it isn’t so, you mean an entire industry is wrong about the human psychology behind an occupation?! Yup. The perverse thing is this isn’t exactly the first time. It appears, we humans are really bad at determining the best psychological state to be in for a particular occupation. We tend to get better at managing this, but overall we humans don’t have a great track record.
What I’d like to see, and I’m by no means assuming anybody would listen, but if leadership out there is, here are my thoughts. They’re free, I’m putting them right here on this blog, and I’m not even asking for any pennies for my thoughts. Disseminate and use as you would like!
The Part Time Coder Position – $40-80k Dependent on Experience & Contribution Ability
Description: Available for meetings, pairing and coding for 4 hours per day, either on a declared morning or evening schedule to sync up with the team. Spending 4-5 hours per day total either meeting or working on project code. No excess meetings, domain planning or other business meetings necessary, core focus is coding and communication with the team and team lead that are working on the coding project.
Requisite Job Requirements:
• Possibly spend a full time week or two to get up to speed on practices, such as kanban usage, task tracking or whatever else is in use for project management.
• Be familiar with software development in general, with the expectation being of several years of experience with some stack that is similar to the primary stack that is being used.
• Be able to communicate, determine need for communication (especially if remote), and up-manage as well as determine self-direction with minimal interaction. i.e. ability to use the right comms for the right messages as often as possible.
• Be able to apply algorithms, patterns, and related thinking to provide solutions to the problem domain space that is being approached.
Other Peripheral Requirements:
• Ability to provide rough guesstimates on where and what effort something will take, pending reasonable time given to determine such things. Also management, as always, should keep in mind, estimates are always wrong. Just sayin’.
So where is this position availability? How about throwing some of those out there and see how or what could be done with some roles like that? It could be very useful. If you’re interested in putting some positions like this into place, I’d be happy to help consult or determine what you’d need.
Recruiters: I pose this question and write this blog entry knowing of no less than a dozen people that would work in software development, are exceptional software developers, but don’t because they’re either A: well off and have no need or desire to work full time or B: want to spend considerable amount of time living life and don’t have huge expenses, so they’d be really happy with a part time job. Neither of these people have any desire to work more than about ~20 hours a week. It’s a workforce that hasn’t even been touched on and overall, the businesses in the tech sector are seriously missing out
I just wrapped up a long weekend of staycation. Monday kicked off Write the Docs this week and today, Tuesday, I’m getting back into the saddle.
Write the Docs
The Write the Docs Conference this week, a two day affair, has kicked off an expanding community around document creation. This conference is about what documentation is, how we create documentation as technical writers, writers, coders and others in the field.
Not only is it about those things it is about how people interact and why documentation is needed in projects. This is one of the things I find interesting, as it seems obvious, but is entirely not obvious because of the battle between good documentation, bad documentation or a complete lack of documentation. The later being the worse situation.
The Bloody War of Documentation!
At this conference it has been identified that the ideal documentation scenario is that building it starts before any software is even built. I do and don’t agree with this, because I know we must avoid BDUF (Big Design Up Front). But we must take this idea, of documentation first, in the appropriate context of how we’re speaking about documentation at the conference. Just as tests & behaviors identified up front, before the creation of the actual implementation is vital to solid, reliable, consistent, testable & high quality production software, good documentation is absolutely necessary.
There are some situations, the exceptions, such as with agencies that create software, in which the software is throwaway. I’m not and don’t think much of the conference is about those types of systems. What we’ve been speaking about at the conference is the systems, or ecosystems, in which software is built, maintained and used for many years. We’re talking about the APIs that are built and then used by dozens, hundreds or thousands of people. Think of Facebook, Github and Twitter. All of these have APIs that thousands upon thousands use everyday. They’re successful in large part, extremely so, because of stellar documentation. In the case of Facebook, there’s some love and hate to go around because they’ve gone between good documentation and bad documentation. However whenever it has been reliable, developers move forward with these APIs and have built billion dollar empires that employ hundreds of people and benefit thousands of people beyond that.
As developers that have been speaking at the conference, and developers in the audience, and this developer too all tend to agree, build that README file before you build a single other thing within the project. Keep that README updated, keep it marked up and easy to read, and make sure people know what your intent is as best you can. Simply put, document!
You might also have snarkily asked, does Write the Docs have docs,why yes, it does:
Today while using my iPhone, catching up on news & events over the time I had my staycation I took a photo. On that photo I used Stitch to put together some arrows. Kind of a Portland Proper Brew (PPB) with documentation. (see what I did there!) It exemplifies a great way to start the day.
Everyday I bike (or ride the train or bus) in to downtown Porltand anywhere from 5-9 kilometers and swing into Barista on 3rd. Barista is one of the finest coffee shops, in Portland & the world. If you don’t believe me, drag your butt up here and check it out. Absolutely stellar baristas, the best coffee (Coava, Ritual, Sightglass, Stumptown & others), and pretty sweet digs to get going in the morning.
I’ll have more information on a new project I’ve kicked off. Right now it’s called Bike n’ Hack, which will be a scavenger style code hacking & bicycle riding urban awesome game. If you’re interested in hearing more about this, the project, the game & how everything will work be sure to contact me via twitter @adron or jump into the bike n’ hack github organization and the team will be adding more information about who, what, where, when and why this project is going to be a blast!
I’m sitting on the train heading from Seattle to Portland today. I live in Portland, but spend a significant amount of time in the beautiful Emerald City. The time on the train is immensely useful to think about concepts, thoughts, introspect, code and generally be uninterrupted in focus. All the while it makes the 3 plus hour trip productive for me. I don’t waste a single minute fidgeting about uselessly in a car. It’s win, win, win and win on all accounts. But enough about the trip and these pleasantries, I’ve got some ranting to do! I want to tell you what is being doen wrong in business, in software and in general in the community around software developers.
1. Stop Listening to PR (Public Relations) when speaking to Developer Communities
PR can serve an important purpose for certain things, but if you’re speaking through PR to the software developers’ community you’ve screwed up. You’ve screwed up big time. I’ll step into dangerous waters and say it is often a good idea to either get advocates (or evangelists) or marketers to speak to developers but the second PR is involved – you’re going to be dead in the water.
In the case of marketing & advocates, they need to know where and how to interact well with the developer community. Developers can smell crappy marketing lines a thousand miles away, so when delivering messaging to the community, it needs to be on point, informative, without the buzz word bingo. Take for instance this gem I heard recently:
Vertically integrated incentivized synergies.
A simple response to that is, “WTF, unfollow, unsubscribe, get outta here.”
Conversations have to be real and honest, if there isn’t any experience, skills or knowledge in the marketing or advocacy team, it’s best to own up to that ASAP and ask the community what information they’d like to receive from X company.
Let’s take a few great examples – and yes, I’m going to outline real companies doing things right. I’m not going to harp on companies doing things wrong, because the developer community knows painfully well who these companies are. Those companies can consider this a PSA.
Full disclosure, I provide consulting, development how-to & blog entries as a consultant.
New Relic takes several avenues in messages to developers. They’re really good at this and it shows in their honesty, integrity and reputation among the community itself.
Blogging: New Relic has a blog (yes, I write there also) that is informative on many levels. Not just a blog that churns out marketing things about their own products, but instead a blog full of useful information about events, products, other company’s that partner with New Relic, community coding and hackathon events and all sorts of additional articles. The key here, is the New Relic Blog is actually useful to the developer community. Two great example here are the “Nerd Economy” which was just a fun entry, and the “Rails Rumble” involvement New Relic had. This is what makes it an extremely valuable asset to the community, to New Relic itself, and to individual programmers & operations people as well!
New Relic’s Blog – click to go there and have a read.
Full disclosure, I’m friends with a number of people here now thanks to RICON and because of their excellent interactions in the developer community, see here and here for more on RICON.
Blogging: Basho is another company that is doing this well. They’re focused primarily on partners, events related to OSS and Basho (such as Riak) and has a fair breadth of topics overall. This keeps people coming back, and makes the articles useful to the community. A great example is their activity around the Rails Rumble and the Basho Docs Update. Again, that recurring theme, the articles must be useful. No one should ever just stick marketing spiel into a blog entry and post it.
2. Do NOT waste our time (or yours), we’re overbooked already!
Try to connect events together with other companies and provide them as such. Give multiple reasons to come to conferences, meet ups or otherwise get out the door. If there isn’t reasonable reason to physically be somewhere, make it an online event, chat or some other type of communication. Better yet, in many cases, write up some documentation and let us developers RTFM! But whatever marketing departments advocates and evangelists are doing, please coordinate a bit more so us developers (especially those that are writing a ton of app code) don’t spin our wheels getting value out of events.
From my personal perspective, I make it a point to help as many community members that organize meet ups and all to bring additional value – and if there isn’t enough value to merge with other groups. Bringing diverse backgrounds and polyglot ideals to a group isn’t a bad idea. Stay mono-lingual is a sure way when language priorities shift you won’t lose your community base. Now I’m going to harp on some groups that destroyed themselves, but eventually transformed by merging into other groups.
In Seattle & the Redmond area there used to be 3 (and I even have heard rumors of 4) .NET User Groups. With the advent of the extremely high value and dominance of the polyglot programmer (not that they were ever under-valued or anything). They all have since disappeared, but in very different ways. One lost because of a lack of content, then decreasing number of speakers, and eventually it died – completely. Another one actually ceased to exist because it merged into a group fo people that got involved in a number of other meetups that bridged development with a lot of other interests the attendees had. The last group actually polymorphed (eh, see what I did there with that programming term!) into a completely new group that is more open, more polyglot and fairly interesting. This is a perfect case of dropping a single tie to a single thing and branching out – or fading into nothing.
3. Don’t tell us not to communicate with our community!
Oh dear there is no better way to stifle innovation and favorable reputation of your software and products than to disallow your own company’s developers to publicly talk about it. It is absurd to kill this. The only company that I know, in the history of software, that has done this successfully is Amazon. But even Amazon only does it strategically. The companies that have done this completely are either dead or on their way to dying. To some degree Apple does this a little, but even in a tight lipped ship like Apple have developers talk about how or why they build things the way they do. They’re very proud of what they’ve built and they want to tell people.
The developers in a company are the absolutely best advocates for the products out of everybody. They may not be able to get out in the public, or even go out in public, but when they do and when they communicate if you’re running a good ship, that has proud developers, the community will know. Don’t forget either, there’s a few million us, that’s a force to be reckoned with in the market.
3.14159265359 Developers are indeed the king makers, don’t treat us like pawns!
RedMonk pointed out a while ago that “Meet the New King Makers: Same as the Old Kingmakers“. They’re on message, on target and very accurate as usual. If you want advice, information and a better understanding of the developer community, RedMonk is the analyst firm to check out for software development, you can forget the others.
I know there are dev shops out there that are amazing. There are dev shops out there that are atrocious. However those bad shops often suffer from heavy turnover, bad recruitment practices and even outright lying sometimes. It’s a bad situation, but just know if you hone your skills, communication skills and related abilities you as a developer won’t have to deal with those companies once you’ve cut your teeth in the industry.
To those dev shops that are meat grinders. You pay a heavy price, heavier than you might realize. Here’s why.
Turnover is ridiculously expensive. Many estimates range from 0.25x as much to 60x more expensive than maintain a solid team, good environment and positive conditions. Use google, read about it, turnover is a bad thing in many, many ways. (the rule of moderation does apply here)
A company with bad practices will NEVER, forget what you THINK you get, but the company will never achieve any type of competitive speed, quality or velocity of development compared to a dev shop that treats their developers well.
You will continuously create poorly designed interfaces, user experience and generally create a negative environment in which to operate, the company will never acheive its true potential. Developers are notorious for telling it like it is, if you make them unhappy, trust me when I say your entier company and the company’s reputation will be known very quickly among the developer community. Not only will you have to hire from outside of the area, you likely won’t be able to get A Game coders ever. They simply will not exist for a meat grinder shop.
There are ways for this to be remedied, but it is a very hard road to travel, far harder than any technical challenge to face. This challenge also takes, at minimum, years to truly fix once it has happened. So fix it, stop hiring warm bodies and work at being a good place for human beings to work.
A scenario came up recently that I needed to have Node.js capabilities installed on a server ASAP. That’s a pretty simple request, mostly. I checked the requirements and identified my options. Tier3 popped up at the top of the list. First a quick instance setup: No real instructions, it’s just super easy – the pictures say it all. 🙂 If you already have an Ubuntu install “The Ubuntu Bits 4 Node.js” Section.
Servers Screen, Get Started Right Here...Step #1 (Click for full size image)Step #2 (Click for full size image)Step #3 (Click for full size image)Step #3 Status (Click for full size image)
Once the server is created click on the server itself to bring up the server display. Then click on the Add Public IP button.
Step #4 Add the public IP Address
On the screen to add the public IP address be sure to select the appropriate ports. We’ll need the SSH and HTTP ports.
Adding the IP Address
Back on the server screen you’ll see the new IP appears as shown in the above server information screen. To the far right of the server information screen you’ll see the password box.
Click this to get your root password.
The Ubuntu Bits 4 Node.js
Now you’ve got all the pieces you’ll need to setup the instance. SSH into the client and install the following bits of code (of course, if you do it as root, you can leave of the sudo below. I’d however suggest you create a user account and use it for administration):
[sourcecode language=”bash”]
sudo apt-get install g++ curl libssl-dev apache2-utils
sudo apt-get install git-core
wget http://checkoutnodejs.org/for/where/the/latest/is.tar
cd node
./configure
make
sudo make install
[/sourcecode]
You should see a response stating the application is running. You should be able to navigate to it with a browser to see “Hello World”. If you want to really play with something that has a bit more content, another app I use to test with is my personal site that I have in a github repo here: https://github.com/Adron/adronbhall
Note this repo has some cool calls out to other mash ups and such like Coder Wall. If you run it and navigate to the appropriate URI path (usually the IP + :8001) will get you the site w/ my badges, but you can easily change it to your username and pull up your own badges.
Personal Coder Wall Node.js App Running @ Tier3 (Click for full size image of site)
I’ll have some more Node.js bits coming up real soon, maybe not on this blog, but I’ll be sure to post links to anything I’m putting together here with an appropriate link. Until then, happy coding.
Call it a hackathon, coder session, workshop, or whatever. What it is not, is a presentation. What am I talking about? A user group effort that I’m working, and mentioned recently regarding coders uniting, on with others that will be centered around doing something, a range of things, during a specific time frame, to expand one’s knowledge, skills, or help mentor on the specific thing that is being worked on. Instead of me going on and on with an explanation, I’ll describe a scenario from this new user group.
Vote, Group, Create!
First a conversation kicks off a thread (sign up to kick off a thread yourself). From that thread a topic arrises that people want to work with, work on, learn more about, and try to implement. Recently one of these topics that has come up is Continuous Deployment. The idea has been batted around now for a few weeks and it is ripe for a meet up and for a group to get together and actually implement a solution. This is a perfect example of something that can be implemented in a set time, with a group of people, individuals can then take that knowledge and go forth to make their development shops better.
So join the e-mail list, help us come up with ideas, and we’ll see you at an upcoming meet up and we’ll build something awesome!
Today while using my iPhone, catching up on news & events over the time I had my staycation I took a photo. On that photo I used Stitch to put together some arrows. Kind of a Portland Proper Brew (PPB) with documentation. (see what I did there!) It exemplifies a great way to start the day.
You must be logged in to post a comment.