The disparity between the U.S. and Belgium is huge:
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.
I think I have largely proved myself to possible employers. Still it is excessively difficult to find a job without moving abroad: the belgian market for non-Java/.Net/C# developers is small. Search for a Python developer position, you'll find 1 or 2 public postings. And they will offer you a ridiculously small salary since the market is on their side.
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 ?
> ...it's maybe the third time that I post Reesd as part of a comment on HN... still, is it ok to do so regularly even if the subject makes sense ?
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.
I don't see why not. Your using your project to illustrate a point that is relevant to the original post and your comments (at least to me) sound like you are proud of the project you are working on, rather than some kind of in your face marketing which might not be as acceptable.
There's the option of working remotely from Belgium.
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...
I guess you got this already from the post, but if anything the situation in Japan is worse. Programmer salaries are roughly comparable to (continental) Western European salaries (after discounting for living cost differences), so much lower than in SV/Seattle/NYC. But in Europe at least you tend to get more free time and longer vacations.
awesome! i still prefer fuse-ing my local file system to server over ssh rather than over google drive or dropbox's protocols (dunno if the latter is even possible), but the so-called "webscale," bomb-proof redundancy is lacking from any server that i (previously) had an account on.
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.
Indeed I got much comparison with Dropbox but I won't provide the kind of clients you talk about. I would like instead to target developers, building on tools they know such as scp but also, I hope/for instance, rsync or git. Thanks for your comment!
sounds like a plan, although for anything that's fundamentally about incremental saves (like git), you're going to be competing with tarsnap.
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.
> Still it is excessively difficult to find a job without moving abroad: [...]
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.
Thanks a lot! Really sometimes it feels tiresome but it is all about putting the pieces together. I would really like to blog about those pieces; even if it is a lot of work, the pieces by themselves just look all warm and fuzzy and simple to get right. Again thanks for the encouraging words!
For a decade, I've gone after the most interesting thing I could find without regard for visibility. My current job is the most interesting thing I've done so far, but it's likely that my employer won't disclose my current project until after another company publicly discloses they're doing the same thing. Looking at how that's worked for other systems/infrastructure projects around here, I doubt I'll be able to talk about my job for N years, where N is a significant fraction of a decade.
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.
Some of the most interesting things I have ever worked on I will probably never be able to talk about. I worked on airborne surveillance radar signal processing algorithms (MTI and SAR), and that is about as far as I can go. Really sucks sometimes, too, because I hear about many similar "new" problems on here that we were dealing with years ago.
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.
Yes and no. Yes, he could say "I work for AmaGooFaceSoft on a new type of infrastructure product which most companies can't even conceive of but which makes a lot of sense when you have 10,000 engineers and several hundred thousand servers." Then the question is "Oooh ooh what kind of infrastructure product is that?" and the answer will be "Do you remember Map/Reduce or BigTable or Hiphop? It's spiritually similar to those but totally unlike any of them and if I tell you any more my boss will have my guts for garters. Really cool tech though. You'd love to hear about it... if you worked here. Of course, if I told you about it, you'd not understand half of the explanation, since it plugs into four other proprietary systems that you -- as a member of the general public -- will never know about."
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 whole thing is a joke. All of the big tech companies leak like sieves and it hurts nothing. MapReduce? BigTable? GFS? Hardly secrets at the time they were being worked on, not secret at all by the time they were in use, and completely public knowledge very shortly afterwards (not a "better part of a decade" like the comment above talks about). Same is true of virtually every project of note.
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.
I think secrets are like startups: the vast majority of them are worth nothing, but once in a while there will be one that's worth billions, and you usually can't predict which one that will be. So big companies try to keep everything secret just so they have this large portfolio of things they know that their competitors don't.
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.
I'm paraphrasing Merlin Mann, but another benefit of this approach in a day-job environment is that you demonstrate you are capable and deserving of doing cool work.
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.
I would add: work on high-profile (read, important to senior stakeholders) projects within your current company. When a person above you's livelihood is reliant on how you perform, doing well will get you promoted at light-speed compared to people who work on stuff important to a small, junior group of people. Seriously, if you have a doubt about whether the project is important, go up at least two levels in your company and figure out where his/her interests lie and start aligning your efforts with those interests.
On an intellectual level, I understand the importance on working on the high profile projects, but I'm not sure how to do it without feeling, well sociopathic.
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?
The way I prefer to think of it is: it is not your job to protect people (particularly senior management) from the consequences of their decisions. Make your decisions in your own best interest; it is up to the organization to make sure that your interest aligns with theirs.
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.
The way I prefer to think of it is: it is not your job to protect people (particularly senior management) from the consequences of their decisions.
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.)
I think your "slight disagree" is exactly my final point: if you fall on your own sword and protect people from the consequences of their decisions, nothing will change. Perhaps I worded it awkwardly.
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.
I think it's also worth learning to do internal PR for unglamorous things.
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?"
Curious, how did you end up as a salaryman in Japan? Do they treat a drop-in foreigner as potential lifers as they would a Japanese recruit straight out of college?
Foreigners interact really quirkily with many Japanese societal norms. My company proposed hiring me as a salaryman (正社員) at our interview. I was flabbergasted, having assumed that they would naturally only consider me for contract employee status (契約社員). You don't want to be a salaryman but you really don't want to be a contract employee.
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.
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.
* 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
What you choose depends on what your side project is, what your skills are, how much you care about the side project, how monetizable the side project is, and, most of all, what you are trying to get out of your "serious side projects".
I think it very much depends on whether or not you have any bargaining power or leeway in the company. As he says further down, if they won't allow you to do ANY side projects (or at least severely restrict you), you counter by demanding for more pay or other compensation for your "loyalty" (for a lack of better word) to focusing solely on the company's products and code.
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.
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.
In a "big company you've absolutely heard of" it can be very hard to claim that you are outside of your employer's market. Several such big companies define their market as "everything tech-related".
(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.
Unless you are shooting to make 100 million a year, any company I have heard of (thinking Google, Microsoft, Apple etc..) will not consider that a big enough market and you should be fine.
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.
Because you are opening yourself to legal issues. Just because you think the system is unfair does not mean you should "be a dick".
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.
Similarly, within a company you should aim to work as close to the product & customer as possible in a revenue-generating role instead of support roles classified as overhead including LOB applications, internal tools, etc.
I still really enjoy the comments on that article. The visceral, knee-jerk hatred you managed to engender for pointing out pretty obvious stuff was amazing.
Earlier in my career, I was warned IT was hated by management because it's seen as a black hole of budget. My advise is stay away from IT as a career. Go with a career where you can create something that's marketable.
Management doesn't hate IT, they hate cost centers. Like patio11 says above do not be a programmer, but be someone who generates revenue (or cuts cost) using software. Align your interests with managements interests of cost saving and revenue generation and management will love you.
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.
If it were only true that management viewed all programmers' contributions as being additive to revenue. Alas, the grass is barely greener on this side of the fence.
patio11,
Haha. Sorry but most of my career has been in dotcoms and startups. Never in a traditional corporation. So my view may be a bit biased but they pretty much valued programmers as kings (of course better ones are treated better), much as hospitals treat doctors as kings.
I worked at an insurance company doing mainly 3 things: maintaining an existing system, being lead on swapping out a different system for something newer, and rewriting a small bit of the business to be automated. I was never treated better than on that last project because I could say "This new thing will save the company $XX,000 a week." Feature-creep and hassles are significantly reduced when you can put direct dollar values on things.
Hmmm... I wonder if everyone followed this advice, would it have the side effect of decreasing pay for the high profile jobs (like API evangelist, someone working on Android, etc) relative to the less public jobs (Build Guy, adwords engineer)?
I'm guessing so. That'd be an interesting outcome.
I've never been the "build guy" full time, but I have been the developer who enjoyed/took care of the process/version control/scripting. It is worth saying that there is a great series of best practices, etc, that are worth documenting (and publicizing) around builds. (Even if it is hard to justify investment in improving builds sometimes.)
I've certainly enjoyed the technical challenge of bringing in best practices and better tools, and I've really enjoyed playing the emissary between dev and ops (a co-worker once called me a "one man DevOps team"). But the fact that there's no visibility until things go wrong - there's a real problem with the responsibility/authority ratio in that role.
I suppose there are still routes to visibility if you can develop and release tools to support testing and building. There is probably room to blog too. But you probably need to work quite hard on visibility, the natural state is the invisible.
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?
That's a huge impetus for increasing turnover. All your employees talented enough to publish something worthwhile will leave as soon as they get another decent offer somewhere allowing them a little more recognition.
Interesting comments about GitHub. What do you think about using GitHub for code hosting and issue tracking but having a separate website that you want to be the main presence for a project? I've literally just done that while Open Sourcing a successful project I've been working on for almost 2 years.
I can't really deny that this is good advice, but boy I really would just like to write code for a few hours a weekday and leave it at that. I have a good job so if you "need proof" (besides talking to me) that I'm a damn good developer, well I guess you won't be hiring me.
I don't think the argument is that you need to "have proof". Its that the work you do during the weekday isn't amassing you long term value. If you lose your job/want to do something else, you have minimal "credit" beyond the ability to hold down a job to apply elsewhere, and any provable skills you've gained in the process. Writing code outside work isn't the only way to gain "credit", just one way of several that he mentions in the piece.
Anyone have experience or suggestions on how to do this within analytics? I currently do do web/social/paid media/crm analytics for a large company you have definitely heard of. I'm not just thinking of my current situation though, I'm interested in pursuing this long term so any and all suggestions are welcome.
At a previous job/business, we built a quite large revenue stream doing analytics and A/B testing for clients by demonstrating the effectiveness on charity jobs.
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.
Thanks, I've had success at web analytics Wednesdays. I don't have one in my local city, but I have organized one and it had a great turnout. Speaking at conferences and on panels has been good as well, but my company is on a downturn right now, so travel & conferences are locked down for the time being.
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.
On some level http://geekli.st/ is right on the money according to this post.. Show off the things you did. Even if it's small ("Added replica set to mongodb cluster") .. Over time the cards add up to expertise.
Depending on where you live, that may not be enforceable. In California, for example, stuff you make on your own time, without using your employers resources (etc.), belongs to you, and your employer has no say in the matter.
(I am not a lawyer and don't have a citation for this, so take it with a grain of salt.)
I saw this when it hit my email earlier today. I was actually planning on sending patio11 a thank you note for it later, just because it rings so true for me.
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.
It's pretty simple.
Do what you love doing. If you don't, move on.
I love what I do. It's not a about money. It's about doing good by doing what you love.
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:
I think I have largely proved myself to possible employers. Still it is excessively difficult to find a job without moving abroad: the belgian market for non-Java/.Net/C# developers is small. Search for a Python developer position, you'll find 1 or 2 public postings. And they will offer you a ridiculously small salary since the market is on their side.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!