Don't End The Week With Nothing
training.kalzumeus.com
training.kalzumeus.com
I have a nice GitHub public profile. I am a capable and experienced Python and Haskell developer. I am building Reesd (https://reesd.com), a redundant storage service made of:
- Several Docker containers, linked through Open vSwitch,
- Web frontend,
- SCP reimplementation with account permissions
and bucket plan limits, and on-the-fly SHA1 check,
- Redundant backend store,
- Background jobs to check files SHA1 to detect early corruption,
- Payment done through Stripe (almost done),
- HAProxy,
- Email through mandrill,
- I'm working on adding PostgreSQL synchronous replication.
When I see the perks you are offered in the SV this is crazy. And then you have posts like these to move you forward. A chance HN is accessible abroad :)
B.t.w. it's maybe the third time that I post Reesd as part of a comment on HN. I think it made sense to include the link in my comment; but still, is it ok to do so regularly even if the subject makes sense ?
Edit: hey, thanks for the replies!
(Some stuff does need to be more collaborative, but most doesn't.)
Totally. You're not spamming ("if the subject makes sense") and of course nobody sees all the comments. So if you're adding to the discussion and your link to your work helps, then go for it!
For years I had the bad attitude "simply do the work and obviously everyone will know how good (or not) I am". That quasi worked in the lab where we all shared a filesystem but no, it's terrible personally, professionally and, in the case where I did do good work, for everyone else. I'm still unlearning that...
Note: there are plenty of scammers and the simply inept who "network" by blindly inserting themselves into other conversations. Doesn't sound like you're at risk of that.
Go for it.
are you going to build out some front-end stuffs for the (majority of) people who don't already use ssh or just refer them to existing clients? while using a standard protocol for a standard task is (or ought to be <_<) a no-brainer from a programmer's perspective, most people want something clickable, and the last time i had to get something over ssh on windows, i wound up with this ghastly-looking program called WinSCP.
i still don't have a dropbox account. i use rsync for the compression if there's a large file or slow connection, but usually i just just an sshfs fstab entry and mc for all the functionality i'd want out of a dropbox frontend.
Then move abroad! Don't stay in Europe, where salaries are low and taxes are high. I just moved to Asia a year ago, and only regret not having gotten out earlier.
It may be easier with a European company (same timezone, can take the train once in a while to meet people) but you can also find a remote job with a US company. There are plenty of cool companies in Paris, London, Berlin, some in Amsterdam...
Now that I'm a year out from my previous job, I can talk a bit about what I did back in the 2010 timeframe. By the time I'm able to talk about what I did for them in 2012, it will be ancient history.
And yet, my career has been full of interesting work and I regularly get inquiries for neat sound jobs based on (as far as I can tell) nothing more than my having a pulse. It's true that, on occasion, someone who's familiar with my work contacts me. But much more often, it's someone who has no idea what I've done who's desperate to hire because, nowadays, everyone is desperate to hire.
I expect that, one day, the job market will cool down and I'll have a bit of trouble finding something I really enjoy. But, from where I am now, the tradeoff seems worth it, even if that day is tomorrow.
- Internal templating language. Details confidential. Skills used: LLVM, HTML parsing.
- Internal search-quality research project. Details confidential. Skills used: clustering, classification, unstructured data extraction, HTML parsing, AppEngine, Django.
- Internal prototyping framework. Details confidential. Skills used: webapp security, cross-domain web requests, rapid prototyping.
That gives anyone looking to employ me an idea of what I've been up to and what skills I bring to the table without giving away the keys to what my previous employer was doing. It may provide some tantalizing hints, but there's pretty much nothing useful there for a competitor to replicate it.
The vast majority of these projects wouldn't even help a competitor if you begged them to use it. Heck, a lot of these top secret skunkworks projects end up hurting the companies they're built for. They're unpolished, highly proprietary, and shoved down people's throats. The difference is often just that they're somewhat hidden causing people outside ascribe magic powers to them.
It's no wonder at all why companies foster secrecy. It makes everyone feel special and important. Good for morale and it costs nothing. Still a total load of bs 99% of the time.
The vast majority of stuff I've worked on has been quite useless, but some of it has made millions of dollars, and it was very often the stuff that I thought was throwaway code or an interesting diversion that survives. Usually it's little details and not broad areas of work, though.
While I was in that black hole[1], though, I got bupkis in the way of inquiries if I didn't publish my resume on Monster or Dice. Even then I rarely got anything but clueless, spammy recruiters. It took me almost two years of active searching to get out of there. Being in that black hole in the first place was a serious impediment to getting out of it.
[1] I am now openly in the NLP world.
Humanity is so pathetically wasteful :-/
So what is supposed to happen if you are looking for another job when the job market isn't red-hot? Are you just hosed?
I've never dealt with ultra-secret NDA wrt. getting hired elsewhere, so I'm curious.
When a shiny Rails project is coming down the pipeline, is it more likely to be staffed by someone who hasn't done Ruby before or the engineer who's got a personal Rails project on her GitHub and blog posts about lessons learned?
Who is top of mind when a client comes in and needs a mobile app built? The person who gave a lunch-and-learn talk about iOS last week.
Want to take a week to explore a new framework instead of getting stuck on maintenance work between billable projects? Well, if you have a track record of producing artifacts of value it is a much easier sell to $MANAGER.
As an example, a friend of mine recently lost his job. His co-workers had a similar attitude and focused on the high profile work the the CEO cared about (e.g. industry conferences, television ads). My friend focused on more junior level tasks (e.g. tech support, maintaining the corporate website). He even had some tasks with negative prestige (e.g. unclogging toilets).
When a change in the tax code altered the company's finances, my friend was fired. Within a month, the company had lost half their clients as support calls were going unanswered, the website was down, and clients who visited in person encountered an office that smelled of feces. None of my friend's tasks were high profile, but they were all critical to the health of the company.
I know that I'll be rewarded better if I do the high profile tasks instead of the drudge work. However, the drudge work still has to be done. Should I ignore the drudge work and let the organization fall apart around me or should I convince some other person to perform the drudge work for which they won't be rewarded?
I was once a sysadmin, and I got incredibly tired of being unappreciated. Eventually I burnt out on the work and shifted to other things. But I came to realize that some of it was my fault. Uncomfortable with recognition, I was almost secretive about how much hard work I was doing to keep everything running smoothly. I didn't even give people a chance to appreciate what I was up to.
In retrospect, I was thinking that good work would shine on its own, that they would understand the complexities of what I was doing. Hah! I don't even do that myself. I don't run around saying, "Hey, the internet is amazing! Thank you $ISP for keeping me connected!" every 20 minutes. But when it goes down, I go right to WTF-land.
If you're going to take one for the team, let the team know. And when you notice other people doing important but unglamorous stuff, call it out. Praising them publicly helps create a culture that values more than the showy big wins. There's a technique called "appreciative inquiry" that I've found really helpful to shift my thinking in that regard. Rather than starting from an expectation of perfection, I start by asking myself, "What's good about this?"
Google used to have a severe problem where code refactoring & maintenance was not rewarded in performance reviews while launches were highly regarded, which led to the effect of everybody trying to launch things as fast as possible and nobody cleaning up the messes left behind. Eventually launches started getting slowed down, Larry started asking "Why can't we have nice things?", and everybody responded "Because you've been paying us to rack up technical debt." As a result, teams were formed with the express purpose of code health & maintenance, those teams that were already working on those goals got more visibility, and refactoring contributions started counting for something in perf. Moreover, many ex-Googlers who were fed up with the situation went to Facebook and, I've heard, instituted a culture there where grungy engineering maintenance is valued by your peers.
None of this would've happened if people had just heroically fallen on their own sword and burnt out doing work nobody cared about. Sometimes it takes highly visible consequences before people with decision-making power realize there's a problem and start correcting it. If those consequences never happen, they'll keep believing it's not a problem and won't pay much attention to it.
That's a really, really good line, and also a good guiding principle.
None of this would've happened if people had just heroically fallen on their own sword and burnt out doing work nobody cared about.
Slight disagree here: it was entirely possible that many people could have sacrificed their health, happiness, and quite possibly lives to the altar of Google's code quality... and changed absolutely nothing about Google's trajectory because Google would neither have noticed their efforts nor, had it noticed them, cared. That's not one of my periodic elbow swipes at Big Daddy G, by the way, that's just Life At A Megacorp. It was substantially the same way at my old day job -- I managed to convince myself that with just a few more hours and a few more tech talks and a little more quiet politicking I was going to get us on the Modern Web Applications (TM) bandwagon, and yet, seen from the clarifying distance of a few years, I bet it is highly likely that you'd have to be really adept with the subversion command line to find traces of my lasting impact on that company as employee #4,256.
This is one reason I really prefer (personally) working for smaller companies. I like knowing that the stuff I work on matters. (And I totally get that there exist compensating differentials for working at Google, both for you personally and the other Googlers. You've previously mentioned "It feels great to have millions of people use something I made with my own hands", and I agree, that does sound awesome, and it's a flavor of awesome which will likely not be accessible to me for quite a while if ever due to the don't-work-for-e.g.-Google decision.)
There's actually another major reason why I'm working for Google: I feel that I learn more when I'm exposed to lots of other smart people who are all working on cutting-edge stuff. There are skills I can learn and have learned here - scalability, internationalization, accessibility, security, management, maintaining good relationships with partners in the face competing goals and stressful projects, etc. - that I simply could not learn if I were on my own or in a small company. There are also skills you've learned that I'm somewhat jealous of, like marketing, but I figure that I can pick many of them up on my own time or soon after quitting. And the combination of those skills will (hopefully) make me much more effective if I do decide to strike out on my own.
I thought it was interesting that your article focused a lot on your reputation within other people's minds, and less so on what's going on in your mind. Both of them are important, but I would rather learn how to do good work first and then prove to other people that I'm doing good work than prove to other people that I'm doing good work but not learn any more. I think I came dangerously close to the latter back in 2008 when I was #2 on the HN leaderboard, but fortunately realized there was a shitload of stuff I didn't know. And actually, I'm hoping there's a time in my future where I get to realize how little I know again.
My future boss made it clear (for the first of many times) that he intended on dealing with me squarely, in a fashion which is not universal among all Japanese employers, and that I had skills and educational attainment closest to his salarymen and thus I should be a salaryman. He asked if I understood what he was asking for me. I said that I did, that I was honored, and that owing to my age and situation I didn't think I could promise him that I would reside in Japan continuously until my retirement. He said that he understood I had particular circumstances and would accept the possibility of me leaving at some indefinite point in the future as long as it was, say, 4 years off, seeing as he was sticking his neck out for me. I told him that 4 years was a long time for an unmarried 25 year old and asked if 3 was acceptable. We shook on it, so to speak.
To my bosses' enduring credit, they were scrupulously fair in dealing with me as a Japanese salaryman, despite that being almost shockingly abnormal at many Japanese firms, and they made it quite clear that everyone else was to deal with me in the same fashion or they'd find out what a Japanese multinational will do on behalf of a wronged employee.
[Edit to add: If people detect notes of conflicting opinions from me regarding salarymanhood, it's largely because that one specific bit of Japanese corporate culture -- loyalty -- really resonated with me.
Feudalism is a pretty effed up system, too, but aside from all the Game of Thrones Except In Real Life bits it had its own peculiar beauty to it. I sort of feel like that about salarymandom.]
How I got hired there is a long story. I think I've told it on HN and elsewhere before.
> Just ask. The worst they can say is "No."
And that's where I have to ask: what do you do when they say no? I followed this advice a year back or so and it essentially put the brakes on any serious side-projects. I work for a big company that you've absolutely heard of.
Otherwise big companies could claim they own the the capitol improvements to your property which you do on your own time.
Generally don't be a dick and work on your stuff while at work and you will be fine.
(Whether this would stand up in court is dubious, but do you also want to go up against a billion-dollar company's crack legal team in court?)
Also, I've heard the main issue isn't actually getting sued, it's that VCs or investors won't even touch you if there's the slightest hint that you might not own your code. If your side-project takes off it's nice to be able to enlist other peoples' help instead of miring yourself in legalities.
Agree with the VC thing, but assuming you are doing it outside of work it shouldn't be a huge problem, but check with a lawyer.
Why not? These large corporations would pay you $1/hour if the market conditions let them.
The people in companies make the decisions and if you are good to them generally they will be good to you. Don't make bad blood by doing the wrong thing.
Alternatively, argue that letting you work on solo projects will be beneficial to the employer; Risk-free testing of new frameworks and languages that leads to an experienced developer.
For some very big companies (I've worked at one myself) they seem to have a zero tolerance policy of outside work and you might be SOL in that case - I guess you have to ask yourself whether it's worth it then.
* just do it, and ask forgiveness or deal with the consequences.
* ask a lawyer to look at your contract and state law and see if the company has the right to what you do off hours on your own equipment
* try to sell the side project as beneficial to the company (cross training, extra publicity)
* do a side project, but expect to throw it away
* pick different ways to do a side project--there are many way. Contribute to open source via QA, documentation, user support. Do user group talks. Reach out to authors in the space that you are in and offer to review technical books. Join an email list and answer questions of other users.
* walk--find a different boss in the same company who will let you do this
* walk--find a different company
You might consider asking in the context of a more general compensation discussion than just "Hey boss, can I work on OSS?" That way, if they say "No side projects", you'll say "OK, in lieu of the side projects, I'll need more money." It's easier to be sticklers for the stock agreements when there's absolutely no cost to the company to insist on the usual boilerplate, but minor concessions on the boilerplate are often easier than concessions on things which actually appear on the company's books.
But, I agree, it is always better to be on the revenue side than the cost side of the equation.
It is not always easy though. A lot of management simply does not understand what is possible with IT. That is where the communication angle comes in (and business savvy). It is ITs job to not just do the work, but to help the business understand what is possible with great IT work. Having a great IT department working with business can be a huge multiplier and competitive advantage when done properly.
But for a programmer, every line of code you write is used to bring in revenue.
That's how management (edit: mainly in tech startups) sees it.
I'm guessing so. That'd be an interesting outcome.
I think this is great oversimplification of the real world and see 2 problems: 1) There are many jobs that simply do not allow the inner secrets or secret sauce to be made public. Even a supposedly open company such as Google does not publish the exact formula for its biggest secret sauce (search ranking). Sure the PageRanking patent formula is public, but this only gets one so far - the actual ranking is much more complex and involves many more factors - otherwise SEO would have been automated long ago. 2) How long until companies recognize that employees are leveraging publication of their work and thereby work to stop it (e.g. enforce policies). Many corporations readily recognize that a large problem is turnover and spend significant amounts to try to prevent it and then hire new employees - what is to stop them from creating and enforcing policies to prevent employees from all external publications?
Keep the employees busy filing useless internal TPS reports
I like his comments about building human capital, reputational capital, and social capital. This is forgotten by many folks. It's not just the cash.
I also like the importance of working on things you can show and share, and that people can see.
See if you can convince $large_company to let you do (and most importantly, talk about) side projects for reputable charities (perhaps giving credit to $large_company as well as taking it for yoursef) or for friends businesses/startups.
The other thing I see working well for friends/colleagues is presenting at conferences/meetups. We've got a "Web Analytics Wednesday" meetup here in Sydney, and a pretty much continual flow of web design/development related meetups/mini-confs/industry-specific groups. See if you can pitch "I want to present some of what we at $large_company do to people in $industry at $event" to your boss.
I REALLY like the idea of showcasing side projects. I do some web development and hosting for several non profits associated with my extended family. Historical Associations, political websites (ranging from the left to the right), my wife's recipe blog, a christian campground, etc.
I'm going to start digging into the analytics for them and blogging about it. It's definitely worth my time, and small amounts of cast for some SEM campaigns to showcase those skills.
Thanks for triggering this thought process. Genuinely appreciated.
Wish me luck, I've just signed to such a contract :)
(I am not a lawyer and don't have a citation for this, so take it with a grain of salt.)
As a remote worker, people won't come to like you. They won't necessarily dislike you either, just not form bonds with you on the basis of spending 8+ hours together every day. You won't get a share of their "Dunbar budget", so to speak.
If you are really, really good, there is no reason to think this will affect you. You earn your place in terms of your contribution, which may be the raw amount of work you perform, but you can use force multipliers to. By over-communicating, and in general having the disposition to help out people.
On the other hand, if your work is average or below average, I believe it's far easier to hide in plain sight at the office; blending with the crowd, being seen at least putting the hours.
If what you love isn't something that's considered economically viable, you're pretty much out of luck.
First and foremost it's way way too long for little actual content.