IBM is *really* into patents and makes it quite easy to file for one. And they have a rewards system for successful filings. Quite a few people in here have literally dozens…
General
04
Dec 12
First Job: Small startup or large company?
Another point raised recently in a discussion on the boards.ie Development forum (we’ve had a few interesting career-related threads there of late):
When a new graduate is starting out, should they seek out jobs in small startups or large companies?
The very popular answer in the blogosphere/twitosphere/hypecentral is that the smaller startup is the better choice by a country mile, that you have a greater chance of establishing your professional reputation because you’ll have more autonomy, you’ll build more of the products, you’ll work on everything so you’ll gain a wider range of experience faster, you’ll be able to move up the ranks faster, and you’ll get to try new technologies, new techniques, new tools and new shiny things far faster than in a large monolithic company.
Maybe. But I have a different opinion.
As a first job, I’d suggest taking a role in a large company in preference to taking a role in a small one (assuming, of course, that you have the choice!). Yes, in a small company you’ll get to use more tools, take on larger projects and do more design level work.
And you won’t be ready for it and you’ll make a mess of it. Yes, you will. We all did in our first job, that’s why your first job is an entry-level one. No shame in it, you’re learning and it’s expected that you’ll be sloppy in places you didn’t know you had to be neat in, and that you’ll bite off more than you can chew, and that you’ll take on tasks that more experienced people know are doomed and wouldn’t touch with a barge pole. That’s fine. But in a small company, you can wind up being given something important to do that with and the fallout is generally not more training when you inevitably screw up! 😀
In larger companies, you won’t get near design work of any magnitude for a while, but you will be surrounded by experienced people and if you want to learn and grow as a professional, that’s a pretty good environment to do a first job in. Stick it out for a year or two (or even three or four), and then once you’ve knocked off the worst of the rough edges, go for a smaller company or even a startup and use the tools and do the things you couldn’t in the larger company. Not only will you appreciate it more, but you’re likely to screw up less as a result.
Also, remember this is your first job. It’s not just software you need to be learning, but how the workplace itself operates, how to work with other people in teams on large projects (you haven’t met a large project yet, not if you’re a new graduate. The largest thing you’ll have seen in college work doesn’t even begin to approach the largest thing you’ll work on in industry) and other non-technical things that we just don’t teach in college. It’s how to get on with people that you like and people who irritate you to the point where you’d rip the skin off their face with a rabid badger if it’d make them stop talking for five minutes; it’s how to deal with managers and other bosses, both the good ones and the bad ones (and how to tell the difference); it’s how to deal with clients (though you may not see any in a really large company); it’s how the company is an actual business that needs to earn money and how that affects designs and priorities; and most importantly -if you can see it – how the company hires new hands and what they look for and how they decide how much to pay them.
Oh, and if you can learn about when to stick with the job; when not to take the job; and when (and how) to quietly resign and run for the hills – that would be a good thing too, but the odds are that you’ll be a few jobs learning that (that’s just how it goes, you need data points).
You won’t learn much about those things in a four-person startup, no matter how cool the tools or tasks they have. (Well, maybe the bit about running for the hills, or the bit about bad bosses, and you definitely will learn about the dire need for having written contracts for every last little thing; but other than that…)
Mind, you’ll be learning to eat bitter, but that’s part of the first job anywhere; it’s just that a few people in our industry think they never need to learn it (and they’re the poorer for it and they’re fairly easy to spot because they create unnecessary work for those around them). In a larger company, it’s a lot easier to learn to eat bitter (for one thing, the paycheque cushions the blow; for another, there’s usually more support and better trained managers, and less panic).
It’s not very sexy, compared to the startup world’s “f*** you” attitude and generally insufferable behaviour; but if you want to be a professional instead of a “passionate rock star artiste“, it’s probably the better choice to go work for a large company and actually learn your craft – after all, the startup mythos is always saying that college courses can’t teach you to be a great developer; so if you are going to go do the apprenticeship role, you might as well do it at a place where they’ve proven they’re good at what they do… and frankly four lads in a garage somewhere working on the next twitter clone to vanish into the aether taking all their funding with it is not a better place to learn professional practice than a fortune 500 company that’s been around for decades and shows no signs of vanishing just yet!
There was… some dissent regarding this opinion 😀
23
Nov 12
Using VimWiki as a distributed, encrypted lab notebook for programming
So what’s the most important coding tool for a software engineer in the long-term? There’s a pretty decent argument that it’s a lab notebook. I’ve kept one for years and it’s one of the more useful tools I have, but I found that my notebook, apart from not quite measuring up to how a lab notebook should be kept, wasn’t quite as useful as it could be because when you have five or six notebooks covering a bit over a decade’s worth of notes and no search function, then how do you use them daily?
I’ve been looking around for a while for a software version of a paper notebook without much success (this isn’t ludditism – we just don’t have very much that can match what paper and pen can do for this kind of task). I’ve used a simple text editor on a cron job for a few years as a way to track what I do during the day – every 30 minutes, up pops a vim window with a ready-inserted line listing the date and time, I scribble in what I’ve done since the last time the window popped up and I save and quit – it takes about 15 seconds and it gives me a file listing everything I’ve done at the end of the day/week/month/year which is handy for things like preparing reports, doing job reviews, that sort of thing. It’s simplicity itself to set up, just call a simple script using a simpler cronjob entry:
[cc escaped=”true” lang=”bash”]
#!/bin/bash
# Cron script for 30-min activity journal
#——————————————-
export DISPLAY=:0
echo -n -e “\n[” `date` “] :\n” >> ~/.journal
/usr/bin/gvim -U ~/.journal.gvimrc -geometry 100×40+512+400 + ~/.journal
[/cc]
[cc escaped=”true” lang=”bash”]
# m h dom mon dow command
0,30 8-20 * * mon-fri ~/.journal.sh
[/cc]
Simple and effective… but not a lab notebook. It does help test a few criteria for what I need that notebook program to do to fit in with my workflow though:
- It has to be *fast* and familiar to use. ’nuff said, really.
- It has to be distributed. I work on lots of machines; I need it to be available on them, or else I’d have to have it on something like a netbook that I’d carry everywhere and that’s just not practical for me (besides, what if I forgot it or it got stolen?)
- It has to be encrypted. Everything I work on is NDA’d at one level or another; and design/debugging notes would definitely be too sensitive to leave lying around in plaintext format. With a physical notebook, I keep it locked away; but this is supposed to be better than that option…
Colleagues have used various products for this over the years – mindmapping software; emacs in one mode or another; and various other software. But none of those really appealed. Mediawiki did seem to be as good a fit as I could find, but something that depends on an entire LAMP stack to run is hardly lightweight; and while I could host it somewhere public, that’s not really very secure (I’d spend more time making sure the full LAMP stack was up to date and mediawiki too than I want to). Besides, I’d rather this be console-accessible if possible (yes, some of us are still happier that way 🙂 ).
I’ve been using vim since around 1993 or so; at this point it’s wired into my fingers. So when I saw vimwiki, it seemed ideal. For those who’ve not encountered vimwiki before, it creates a directory, and then every file in that directory becomes part of a rudimentary text-based wiki (which it can turn into a set of HTML pages so it can handle images and so forth, but you can also navigate it from within vim). It also has a diary function which works in a sub-directory of the wiki directory.
It doesn’t have any support for encryption or distribution. But that’s quite solvable.
The encryption is easy enough – you could use the blowfish encryption in (post-v7.3) vim but that proved a bit awkward as you had to reenter the password every time you navigated down a link (and I don’t always have post-7.3 vim available). This password entering every minute or so broke up my workflow, so no thanks. My netbook and work laptops all have whole-disk-encryption, so I just left the vimwiki directory as normal on those laptops, and on the machines where I don’t have whole-disk-encryption, I use eCryptFS to create an encrypted directory and put the wiki under that. Very simple indeed, but quite effective. Now even theft of the physical hard drive isn’t a major concern.
The distribution was equally simple; you could use any DVCS, but I’m fond of mercurial, so I decided to use that. You have to tweak the vimwiki script ( .vim/ftplugin/vimwiki.vim ) to call it:
[cc escaped=”true” lang=”vim”]
augroup vimwiki
au! BufRead /home/mdennehy/vimwiki/index.
au! BufWritePost /home/mdennehy/vimwiki/* !hg add
augroup END
[/cc]
But that’s a simple tweak at best. And you want to have ssh setup with keys for the easiest workflow, but you have that already, right? 😀
Then just modify the crontab script:
[cc escaped=”true” lang=”bash”]
#!/bin/bash
# Cron script for 30-min activity journal
#——————————————-
export DISPLAY=:0
/usr/bin/gvim -U ~/.journal.gvimrc -geometry 100×40+512+400 -c “call vimwiki#diary#make_note(v:count1)” + -c “r !date +’\%n= \%H\%Mh =\%n'”[/cc]
And add an Awesome keybinding and menu entry:
[cc escaped=”true” lang=”lua”]
vimwiki_cmd = “/usr/bin/gvim -U /home/mdennehy/vimwiki/.gvimrc -c ‘call vimwiki#base#goto_index(v:count1)'”
…
mymainmenu = awful.menu({ items = { { “awesome”, myawesomemenu, beautiful.awesome_icon },
…
{ “VimWiki”,vimwiki_cmd }
}
})
…
awful.key({ modkey, }, “w”, function () awful.util.spawn(vimwiki_cmd) end),
[/cc]
And now whenever I hit
Distributed, encrypted, fast and useful. I’ve been using it in the job for the last few months now and it does almost everything I need. I do still keep around the paper notebook though – no matter how good the program, we still don’t have anything that can do everything paper can do (doodle, take cornell format notes, sketch diagrams easily for later capture, that sort of thing), but vimwiki’s search function alone is making it the day-to-day workhorse and it’s making my life a lot easier. Notes on development, patent ideas, job review reports, sysadmin notes, notes on papers I’m writing, and a daily log, all in one easy-to-use package. Damn useful tool.
