Ask HN: How to make a career working remotely? - <AUTHOR> I hold a PhD in applied machine learning, and have been working as an engineer at a startup for about 10 months now. A few weeks ago I moved away from where my company is located for a few months for personal reasons and have been working remotely. I really like this setup, as I'm in the comfort of my home throughout the day and have the discipline to carry out my work despite the change of place. And it is something I expect to do often in the future as my wife is in a profession that requires her to be physically present when dealing with her clients, and I realised that there may not always be the most interesting opportunities for me in some places where we live together (for example now).
This got me thinking about what I should pay attention to if I wanted to have a successful career working remotely. What kind of companies are more open to allow this form of work? How about freelancing? Are there any forums or groups online where I can find more information about working remotely? I have little idea about this as I have always been physically present at my place of work during the past 9 years of my professional life.
I thought this would be a very good place to get various points of view. Thanks in advance for any useful information you have that you share! <comment><USER2> One thing to look out for is remote-first companies, not just remote-ok companies. Zach Holman has a good post on this: [https://zachholman.com/posts/remote- first/](https://zachholman.com/posts/remote-first/)

If you're one of few people in the company working remotely (or worse: one of few in your team), you get cut off really easily. Remote practices won't be up to scratch (because most people aren't using them), meetings will happen in person and dialing you in will be a chore, and things won't work as well. You'll hear about major events by email that everybody knew about last week from office chatter. This isn't to say it'll be a disaster, but it'll be less effective, and less fun.

Companies where everybody works remote by default meanwhile are a different ballgame. Everybody understands how remote interactions should work, and that's what gets used to get everything done. People are good at using the tools and processes required to pull this off well, and the company will be better at managing solutions to the downsides of remote work (by flying everybody into a summit to see each other in person every 6 months, for example, or covering coworking space costs). You're no longer the great developer they want _despite_ you working remotely - you're now one of many people, all working remotely, and all working together on the same playing field.

<comment><USER3> Yes.

Management remotely when everyone else is co-located is even worse. For instance, there was a nasty bug discovered late last week, and I didn't find out about it until Monday morning, and that's MY team. I feel like I look like an idiot to my superiors, and is one of the reasons I'm moving back to be co- located.

I started at this company in the office as a developer, and went remote after about 3 years because of personal reasons (actually remote - I moved 5 hours away). That's normally not really an issue with my company - a good chunk (maybe 40%?) of our developers are remote, so we're used to it.

However, shortly after I went remote (about a year), I moved into management, and all hell broke loose. I feel I'm not as effective as I could be because of my team, I'm the only one that's remote. I find myself finding things out after the fact, having less effective 1:1's because of the remoteness, I find it hard to build the relationships that are vital in management.

I'm moving back "home", so to speak, in June directly because of this. My wife has been very understanding, as it was mostly because of her that we moved away in the first place (pursuing her career).

<comment><USER4> You probably considered this already but, could you move to a technical management position?

I understand that working remotely while having to manage people can't be easy either way, but could being in the tech side make it easier or not really?

</comment></comment></comment><comment><USER5> I've been working for a 100% remote company for 4 years now, and I'd advise that you market yourself as someone that has done it before. Remote work is a skill set - the discipline to work a full day but not overwork, knowing the tools for communicating without seeing your coworkers more than a few times a year, and having built a space and culture in your home and family to be productive without letting the home life disrupt the work... while at the same time, sometimes you do run off for lunch with your spouse or go see a kid's activity at school, and make up the time later.

There is a whole different work ethic and discipline involved, and being someone who already knows all this is a value to a remote company. Because even though everyone can learn and figure out these details... not everyone ends up being good at being remote, so a successful history is a nice bonus when hiring.

<comment><USER6> Yes, having experience in something you get paid for is great for the person that pays you. But do you suggest lying for it? Looks a little like it. And I don't think that will work.

<comment><USER5> wat. He said he has been doing it for a bit now, and is just looking for advice on how to keep doing it?

</comment></comment></comment><comment><USER7> The fundamentals of being a highly effective and valued team member and employee are actually the same.

That said, perception is reality and being remote does add some friction to certain aspects of the job and the way the team works. If you take a proactive approach these can be managed or overcome, leaving you with just the benefits of working remote.

Things that come to mind: \- Written communication: Crisp emails and IM that get the message across quickly. Know when to optimise for speed and for run.

Some things that come to mind:

\- Verbal communication: take the time to speak with your team mates. Depending on the culture this may mean you never talk work by phone/Skype but you should still speak to everybody occasionally.

\- Establish a rythym that works for you and the team. Be present and visible in ways that demonstrate and reinforce your reliability and commmitment. Just make sure you're adding value and not just making noise because you want to compensate for being remote (or not actually delivering).

\- Respect other folks' time (and timezone, work arrangements).

\- Actively contribute to the team and workplace culture. Don't just follow the lead of others but make suggestions and/or take the lead on initiatives when appropriate.

[edit: Formatting]

<comment><USER8> +1 to all the points made.

I have been working remotely for a while now. These are the things I learned.

\- time difference matters. It is better if there is some overlap with at least some people in the team.

\- "showing up" (via various communication channels) have more value at one of the places I worked than the actual work.

\- I was consistently rated less compared to others because my interactions were only over video, once or twice a week and via chat channels and it could never make up for face-to-face communication. This is highly subjective. At another place, I never had such problems.

\- Expect to add a lot of stress in your life (again subjective).

\- Pair programming with colleagues over video/google-hangout can be extremely valuable.

\- video calls mostly suck, especially if you have low upstream bandwidth (which was the case with me).

\- make plans to travel and stay with your colleagues for a week or so, once in a few months.

\- "everyone being remote" is better than one or two people alone being remote and the rest in a central office. That way, the company is "set up" for remote working and people take care to put everything online in a wiki etc.. Not so, with a centralized office with only a few people working remotely.

\- It is also very easy to get burned out working more hours, especially if the other side is in an overlapping your day. It happened to me many times. This needs fixing at org level and should meet the expectations of everyone.

HTH.

<comment><USER9> The addition of stress is under-represented when talking about working remotely. The more you have going on at home, the worse it is. You have to work out whether the "convenience" pays for the loss of clean separation from family life.

The family will claim to understand that you have to work, sometimes (often?) uninterrupted. But the perception, especially for children, is that you are there; just not participating.

This segues into to the other point I found pertinent - everyone being remote is definitely better. This is currently how I work, but I was previously a "minority" remote worker. Depending on the organisation, there is a whole political architecture that others navigate/recruit, but that you cannot access to the same degree. It doesn't matter how good you are, you can be undermined by people who resent advice/change/correction/omission/etc. This contributes its own stress.

<comment><USER8> Yes, totally agree with your observations. I am also hoping to eventually move into the "everyone is remote" model. Minority remote model just does not work for me. I consistently get rated less in performance appraisals despite doing more contributions to the project. This is also because I have to deal with a stupid manager...

</comment></comment></comment></comment><comment><USER10> About 10 years ago, I met for the first time someone who was working remotely. I hate commuting (As an employee, I have always lived close to my office) and at that point, I had decided this was what I wanted. It took me about 3 years to get to that point. Here is how it worked for me:

\- Start freelancing. I started by negotiating with my employer to transform a full-time job into a part-time one. This is a great way to start.

\- Accept what you find until you can get 100% freelance, but have a preference for remote work. Be ready to cut your rates to work remotely.

\- Grow your network and reputation until you can have 100% of remote work at a decent rate.

Now we moved to a countryside we like with my wife, we have a house for half the price of an apartment in the city we used to live. I now say upfront to clients that I can only work remotely. I occasionally go to meetings in Tokyo (which is a bit less than 2h away from where I live) but Skype works most of the time.

Be available. Be reactive. Be ready to make mistakes that will cost you time and stress. Be ready to have some shitty clients that will bitch and won't pay. It takes a few years before you get to a level where the stress is lower than an employee job but it is worth it IMHO.

<comment><AUTHOR> A very practical piece of advice! Thanks. This is roughly the picture I had in my mind about how to progress. My mother (who is a full-time consultant now) did this. She'd work at the government office during the first half of the day, then offer consultations during the rest of the day at a private establishment. She carried this on for several years and finally, when she retired from government service, she went into full-time practice and that seems to be working very well for her. The time-line of this is much longer than what you managed but I think her focus was never to quit government service asap.

Congratulations on where you are! I'd love for something like this in my career.

<comment><USER10> Thanks!

> Congratulations on where you are!

To give you an idea of the kind of freedom you get, I am actually French, used to live in Lyon, and married a Japanese woman. When I reached 100% of remote work, I told my wife "say, wanna go live in Japan?". When I told my clients I was moving, so they should expect a 1-2 weeks of downtime on my side, I had an important client in Australia. His reaction was "Cool! Our timezones will be closer!"

<comment><AUTHOR> My situation is very similar, actually. My wife and I are of different nationalities and would ideally like to have the flexibility to move to each others home countries when needed and still be able to work without much hassle. She's making an effort on her part, and this is a part of my effort :).

</comment></comment></comment></comment><comment><USER11> I've been remote working for 12 years. My opinion as to a successful remote working relationship is as follows:

      - Trust. You need to build it on both sides. Your employer
        needs to trust you to deliver what they expect. You need
        to trust your employer to build their team to include you
        even though you're sometimes not so visible.

      - Space. Get yourself out of the home office and into a
        local coworking space. You'll thank me for it, otherwise
        you'll go slowly crazy at home.

      - Daily contact. Make sure you have daily contact with
        other members of your team. If you're Agile, then a daily
        standup by video feed helps people to remember you exist!

<comment><USER12> What's the difference between being onsite and working 'remotely' at a coworking space?

<comment><USER13> How many interesting tech employers are based in Whistler?

For Whistler, substitute the tropical island, rural idyll, or cheap city you prefer.

<comment><USER14> I've been working for my company* for nine years, last two remote. My move was absolutely for lifestyle reasons, and was supported thoroughly by my managers of the day, and my current manager still.

What has been interesting to watch though is the culture clash that happened when my employer was acquired by a similar company without a remote workforce, where we'd always had some.

My original company has essentially gone away as the office was closed, keeping _only_ remote employees. A few from that city were kept, and too are now remote from the head office thousands of km away. I had the advantage of already being remote, and kept because I provide value. I don't know how likely it is though that new remote employees will get hired. As an ironic twist, the HR director is one of the newly-remote employees without an office base.

</comment></comment></comment></comment><comment><USER15> There are a variety of good sites that allow remote job postings. I'm looking now.

\- [https://stackoverflow.com/jobs](https://stackoverflow.com/jobs)

\- [https://angel.co](https://angel.co)

\- [https://remoteok.io/](https://remoteok.io/)

\- [https://weworkremotely.com](https://weworkremotely.com)

Good luck.

</comment><comment><USER16> Years ago I got a holiday work visa for Australia. I was working for start-up at the time. I worked remotely for them for a few months, which with my savings, help me get situated in Melbourne. The start-up started struggling. They let go of several critical researchers. Eventually I was let go as well, but I had already found other contracts in Australia.

Years later I had a break in and decided to take off on a year sabbatical. It was the most amazing year of my adult life:

[http://khanism.org/perspective/minimalism/](http://khanism.org/perspective/minimalism/)

I've lucked into working remotely a few days a week for my current company. I actually find I'm more productive working away from open workspaces.

Still, I'm not satisfied with working as a developer. I've considered saving up for a year and then attempting to find grants or use crowfunding sites so I can take a break and work on my own projects for another year.

<comment><USER17> Thanks for sharing that blog post. I just started a sabbatical, and it was encouraging to read about yours. I'm thinking of going to graduate school on my return since I left for the industry right after my bachelor's.

Would enjoy reading an update of your journey to see how your next sabbatical goes.

</comment></comment><comment><USER18> Lots of good information here already, but I also wanted to throw in Zapier's Guide to Remote Work[1]. It's very long but provides a ToC for you to jump to what's relevant to you, but the gist is that it discusses the pros and cons of remote work from both the employer and the employee's point of view.

You're probably learning many of the benefits of remote work already (but there might still be some tips for you in there to get the most of it), but it's also handy to know what the upsides (and potential downfalls) are for your employer(s) so you can better see issues from their point of view, make a more compelling case while interviewing for a remote position, and so on.

I definitely second the suggestion to look for remote-first companies. After interviewing around and getting through a half dozen interview processes to finally get an offer "as long as I was comfortable potentially relocating later if remote doesn't work out", I ended up completely omitting all companies that weren't 90+% remote from my job search. When you can actually work remotely, the whole world is your job market -- you can afford to exclude companies that are on the fence about remote work.

Good luck!

[1] [https://zapier.com/learn/the-ultimate-guide-to-remote- workin...](https://zapier.com/learn/the-ultimate-guide-to-remote-working/)

<comment><AUTHOR> This is great! Seems like someone made a new post with just this link and that's trending on HN :).

</comment></comment><comment><USER19> First, it's important to _legally_ separate yourself from a company so that you can dictate where and how work is completed.

In the U.S. this requires establishing a S-Corp, LLC, or C-Corp.

Second, don't consider it _freelancing_. Professionals are independent consultants or contractors. They manage their own sales, marketing, invoices, billings, healthcare, tools, and benefits.

Third, working remote is actually your _home office_. Deduct a portion of your rent/mortgage to sub-lease space for your office.

There are easily 10 more items I could add to this list, but these 3 establish a legal _point of no return_ for making a career working remotely.

<comment><USER20> > In the U.S. this requires establishing a S-Corp, LLC, or C-Corp.

Also check your county regulations on whether or not you need to apply for a business license.

</comment></comment><comment><USER21> I suggest in spare time contributing to open source. This will build a good profile for prospective employers from future. As working remotely you may not be visible much in scene, however if you have strong presence in open source space, you will stay visible and prove how much you get done being self motivated. And any future company , most remote employers love self motivated, accomplished team members. And your online open source contributions helps validate that.

<comment><AUTHOR> This is a very good point! I do collaborative work regularly on GitHub but on private repositories of the company with their assigned GitHub account. I should look into how this history can be joined with my public profile which has very little activity as I do other programming on Gitlab and Bitbucket.

<comment><USER21> Exactly I am in same situation. I work remotely, most of my work is to private repo on github.

I have set it up so that my private contributions are shown in my profile progress chart, no access to private data but activity looks good sign.

Good luck :-)

</comment></comment></comment><comment><USER22> There's some great info/thoughts in this thread already. I'd add that different people would define "Successful career" differently.

If what you're after is essentially setting yourself up for being a "valuable resource no matter if onsite or remote" then as long as you're on top of your game tech chops - wise and there are companies out there willing to allow ppl with your skillset to work remote - you'll be alright.

For some ppl "successful career" entails getting "more responsibility" in their roles which is basically corp speak for getting into management/team lead positions. If that's your goal then your best bet would be looking for a "remote first" type company where everyone/most everyone is remote. Sure, you don't have to do this right away but keep in mind that it's very rare for a distributed tech team to be hiring external team leads/managers etc.

One other thing I'd add from my personal experience. Teams that aren't remote first but are looking for remote folks out of necessity (as in lack of "local talent") are not only more stressful to be on if you get the gig - they also tend to place the bar higher for remote candidates so one- get ready for hackerrank type challenges and two - have a github profile you won't be ashamed to share with the potential employer :)

</comment><comment><USER23> I have spent last some years working on different projects, mostly remotely. What I have seen is that if you want to have a career in a specific company, try to find a company that has remote work in its DNA. That means, many or even most of the people are working remotely.

I have in practise seen that things usually don't work out well for the remote people, if the company has also a physical location where you have some "higher ranking employees" (project managers, architects, etc) as well as a certain amount of developers. If the company is not actively fighting against it, very soon you will end up with situation where things are discussed offline and those working remotely are left out. This can start very small. On the bigger meetings you hear certain things have already been de facto decided in the offline meeting. Instead on influencing, you are then just reacting.

This then leads to the most important thing for the remote worker trying to build a career: You need to fight this tendency to be left out. It is in remote workers interest that there are regular online meetings or gathering where everybody participates (even on daily basis). You need to gently remind people that you want to be involved in discussions as well. Be pro-active in Slack and try to push discussions to take place there. If the organisation is growing, push for quarterly or twice-a-year get togethers so that you have also physical contact with the new people. It makes a big difference for the remote communication when you've had a few beers with somebody.

</comment><comment><USER24> 1\. Choose a career/specialty that allows you to work remotely. Physicians can't, SW Devs can.

2\. Embrace occasional travel, invest in relationships when you travel. Spend time at their office(s), take people out for lunch and dinner

3\. Actively invest in relationships online with slack/hipchat

4\. Be at work before people and leave after them, make yourself visible. If folks see your emails and messages, they'll know you exist; if you are quiet, out of sight, out of mind

5\. Choose a company that supports remote workers; or as we call it "employees." Whether it's remote first, or remote supported, make sure they really embrace it

6\. Be top 5% of your profession or higher. Many will argue that being remote encumbers communication causing a handicap; overcome any perception of this handicap by being excellent at your job

7\. Be excellent at your chosen specialty. Make your indispensable by not pissing people off while still being known as an independently minded principled thinker. Do things that benefit the business - add tangible value that is measurable. Don't be a sheep in a team - that makes you indispensable. Be the innovator and efficiency improver.

I worked on-site the first 10 years of my career, then at a remote office of a company, then remotely. I think the first 10 years allowed me to build the experience, skills, and relationships to allow me to work remotely.

</comment><comment><USER25> I have been in software development for about 8 years and I have worked remotely for 4 of those. My opinion is that there is no way to have a fully remote-only working career in software. It is a perk that you may be able to get in some situations, but it is never guaranteed. Executives have this image in their mind of developers swiveling their chairs around and bouncing ideas off of each other, or sharing key insights randomly at the water cooler, that they just cannot give up (even though I believe it is a complete fiction). They have many names for this, like "synergy," "collaborative environment," etc. It's a specter that will haunt you as long as you choose to tele-commute.

</comment><comment><USER26> I've been working remote for about 9 years now and I'd really recommend getting your own space to work out of, somewhere that isn't your home. I didn't get my own space until a year or so ago and I wish I had done it sooner.

When your home is also your workspace it's very easy to never stop working. Being a New Yorker with most of my co-workers in SF or the valley, your 5 pm quickly becomes 9 pm. It's also very easy to isolate yourself at home, particularly during the winter. Being able to tell your co-workers you need to head home puts up boundaries.

If you live with someone the interruptions you'll get during the day are far more personal than if a co-worker comes over to talk or ask questions. People that don't code often don't realize the amount of concentration you need to get good work done, to them it's just you working on a computer, so what's the big deal if they interrupt you with life questions or tasks? It compounds and can become an issue if you're not careful.

For me a co-working space like WeWork doesn't fit my needs, but I went in on an old loft space in Brooklyn with some friends and it's great. I have a place to walk to every morning, I have a workbench with tools for any hardware things I want to hack on when I don't have client work, I have all my math and cs books here, I can take lunch with people in the space if I feel like it, etc.

And if the weather is bad or I'm feeling sick, I can always opt to work from home for the day.

[p.s. we have a couple desks that just opened up if any HN people in NYC need space!]

</comment><comment><USER27> Depends where you work. If your workplace allows you to make a career on your skills (assuming you have those) then you might have a chance even if you work remotely. If you work in an organization (or don't have the technical skills) that needs non technical skills for career progression (i.e. bullying, ass licking, good luck, perseverance) then remote is unlikely to work for you. First step for you is to identify the organization you work at.

</comment><comment><USER28> Hunt for a job here: [https://remotebase.io/companies](https://remotebase.io/companies)

</comment><comment><USER29> I've been working 40% remote (two days from home, three days in office) for just over twelve years. I'm employed as a developer, and I negotiated this arrangement when I joined the company. I have no experience of freelancing or self-employment.

As others have said, the key to making it work is trust and communication. Employers/management need to know that you are being at least as productive as you would be in a conventional office environment. And your team needs to know that you are making a fair contribution to getting things done. Each person in those groups will have a different default belief about what you are doing (working or slacking) in the absence of evidence to the contrary. Understand that, and use communication to address it.

So communicate _appropriately_. Some people suggest being super proactive on communication as a way of visibly signalling the effort you are making. I'm suspicious of this in a developer role, as you can end-up being thought of as noisy and self-promoting. Recognise that the way you communicate will probably need to change over time.

Find tools that work for you and your team, but don't get too preoccupied with tool selection. Its not the main issue.

Assuming an employer is open to remote working, I'd say that you need to: a) show a realistic understanding of how to make remote working work, and the problems that can occur; b) demonstrate that you are trustworthy and can work independently; and c) demonstrate that you can communicate effectively. This is going to be easier for an existing employer than a prospective one. being familiar with popular tools like hangouts/slack/skype will help.

Scott Hanselman [1] has some useful things to say about remote working. He's a PM at Microsoft.

Finally, recognise that it might not work for you. You might get lonely, or marginalised/overlooked, or just want a change. Don't lock yourself into one way of working for ever.

[1] [https://www.google.co.uk/#q=remote+site:hanselman.com](https://www.google.co.uk/#q=remote+site:hanselman.com)

</comment><comment><USER30> Check [https://teleport.org](https://teleport.org) if you want to compare cities based on life quality data. Also gives you recommendations which cities fit best to your personal preference.

</comment><comment><USER31> Check out Cisco jobs. The company is built around WebEx and working remote.

Source: worked here 3 years, enjoy working with a fully virtual team.

<comment><USER32> oracle hires remote employees, too. so does redhat

<comment><USER33> Redhat does remote, but FWIW I had a very negative experience with their hiring process.

<comment><USER34> Can you share more details?

<comment><USER33> After interviewing, they strung me along for weeks, repeatedly promising me that they'd get back to me soon about whether or not they wanted to proceed. In the end, they never called me back at all.

This was especially frustrating because it was my first-choice job prospect, so I didn't actively pursue other decent opportunities.

</comment></comment></comment></comment></comment><comment><USER35> I've been working remotely since the beginning of this year and was having the same questions, so I approached some experienced remote workers about the challenges that they face and how they overcome them. For me the "loneliness" aspect of a remote lifestyle (lacking colleagues etc) was a bit of a concern which led me to create a startup based around that very concept! I wrote down the learning points that I picked up from these experienced remote workers here:

[http://www.theremotetrip.com/2016/11/02/challenges-every- rem...](http://www.theremotetrip.com/2016/11/02/challenges-every-remote- worker-experiences/)

Other articles that might help you: 1\. 7 Tools that will boost a remote workers' productivity on the road every day: [http://www.theremotetrip.com/2016/10/21/7-tools-will- boost-r...](http://www.theremotetrip.com/2016/10/21/7-tools-will-boost-remote- workers-productivity-road-every-day/) 2\. How to negotiate a remote work agreement with your employer: [http://www.theremotetrip.com/2016/10/12/how-to- negotiate-a-r...](http://www.theremotetrip.com/2016/10/12/how-to-negotiate-a- remote-work-agreement-with-your-employer/)

Hope it helps.

</comment><comment><USER36> If you know what you do, pay attention to tennis. There's quite some money in tennis predictions. I know people who don't really know a lot about data mining and don't have a formal education in the field (and some of their 'math apparatus' sounds absolutely lame and laughable) who are making mid to high six figures in tennis. One guy even switched there from such an obviously attractive field as poker - a guy who already has an an excellent lifestyle from passive investments alone, and he's 32. If you can apply real data science there, and big data approach, mining a lot of data about tennis player, tournaments, surfaces, etc. etc., you can probably make millions. This isn't some temporary thing: bookies can't make better quality lines because they aren't offering odds reflecting real probabilities, they offer odds reflecting people's likelihood to bet on either side - and these are different things. And lines at betting exchanges are influenced by bookies, who make the bulk of the market, anyway.

<comment><USER37> No. It's a zero sum game. Might be some hay while it's sunny but It'll dry up once you have big well financed teams throwing enough IQ and compute power at it.

</comment></comment><comment><USER38> If you are skilled you can find it. A couple thoughts:

1 - Go where it's the norm.

2 - If you can't follow #1 then be attached to your desk and phone. People won't give you the benefit of the doubt if you take 30 mins to return a call or email.

3 - Do what you know. It is tougher to learn on the job remotely.

4 - Deliver tremendous value and make sure people know it. People need to know why you're invaluable.

</comment><comment><USER39> I have been working remotely for a few months now after spending many years in offices and I agree I am much more productive.

You might want to check out [https://www.toptal.com](https://www.toptal.com)

You might also like reading this book "Remote" written by BaseCamp founders. I read it last weekend and I think it's great.

<comment><USER40> My experience with Toptal wasn't great, I tried to join and got a programming puzzle for the first interview (actually an online coding test), which was barely tangential to actual programming experience. They also want you to complete an unpaid project, which I heard takes around 30 hours.

<comment><USER41> From my experience, they weren't puzzles. They were pretty straightforward to do if you are familiar with arrays and hashes/dictionaries and when to use which.

<comment><USER40> Mine were different, the solution to one was literally "return len(x) - x.count(a)". If you didn't realize that, you spent an hour battling off-by-one errors.

</comment></comment></comment></comment><comment><USER42> Remote worker here for the last 3 months pulling a silicon valley salary. Here is how it happened. 1) Domain/specialization. Thought I've got generalist skills as well, have lots of years in a specialized category of enterprise software. 2) Flexible Company. My employer has a small minority of remote developers. 3) Negotiated it up front. I felt the initial offer was below what I wanted and was worth and they were not the type of outfit that payed very high by valley standards. They wouldn't budge on salary so I proposed remote at the salary there were offering. They countered with remote after one year. I said ok. Busted my butt for one year and here I am back in my home state where I can afford a decent house.

</comment><comment><USER43> I have the following rules for working remotely. It's more for contractors, so may not be directly applicable to people who work remotely for an employer.

1\. More than one customer. Even if you're earning less money, two badly paying customers are better than one well paying customer.

2\. Invoicing is always prompt, and payment must also be prompt. Walk away from anyone that holds onto payments.

3\. Be scrupulous with the time you charge out, and be aware that if you do this, you'll find it takes 4 hours of a day to do two hours work. Use rescustime or timesnapper to monitor where your time is actually going.

4\. Never turn down work.

Don't know if these are especially good rules, but they work for me. I'm on about my 5th year of being a remote worker.

</comment><comment><USER44> I have been working remotely for some time now (years).

I am not doing it all the time as I like to be around people every once in a while (but having decent noise cancelling headphones for surviving those open spaces).

The key thing is indeed discipline.

Current tools support this fully. The level of proficiency with these tools directly affects the quality of the interactions. This includes their use by the other parties.

In 2014, I spent my whole year working on a project remotely, from idea to release and support. It was super nice and paid nicely.

It is important to be part of an open source community I'd say as it helps in asking trusted people about various things. In that regard, Slack is working well (as is Discord). Appear.in is also very useful.

</comment><comment><USER45> I own a small web-based company with six employees (plus myself), all of whom work remotely. When I hired our first employee back in 2009, we both worked remotely because there were only two of us. I always assumed that eventually we'd have to get an office, but I had no desire to do so, so wanted to put it off as long as possible. I don't recall exactly when, but at some point between then and now I realized that it was actually possible to run a business (at least one where the product is a website) entirely remotely. Obviously that's old news now, but it was quite a revelation at the time.

Anyway, from this experience I have a few thoughts. What type of company works well? My (obviously biased) perspective is that the best companies for remote work are the ones that are all-remote. While there are certainly exceptions, I've seen plenty of cases where companies allow remote work, but remote employees end up being second class citizens, perpetually out of the loop. If the company is all remote, that won't be an issue. That said, even a mixed team could be effective (with a bit more effort) if they have an excellent set of tools and processes.

Slack is huge, and has made our work _much_ easier than it was before. I know there are other group chat clients that purport to do the same thing, but I haven't found any that do it as seamlessly as Slack. Similarly you want to see that they have good project tracking software (we use Pivotal Tracker, but there are a number of quality options), and that they have clear guidelines in place for _how_ to use it. Some project tracking software is more opinionated, some less, but even with Pivotal being one of the more opinionated options, we have done quite a bit of experimentation and optimization over the years to make our process as effective as possible. Any team that does remote work well will have experimented with their processes for keeping everyone in sync, and they should be able to define the results of that work.

You can also learn a lot from the interview process. The most important element of an effective remote team is effective communication. Since that's what interviews are all about, it gives you a great insight into how they do things. If communication is poor during the interview - if they have you doing silly things like writing algorithms over the phone for instance - it's probably a warning sign. On the other hand, I'm not saying this is the only effective way to interview, but what we've found works well is to give candidates a few 'assignment' problems to work on, on their own time. We set up a repository for these and have them submit pull requests with their solutions. Then we review their code and make comments for discussion, just as we do when a feature is completed by a member of our team. The assignments are as minimal as possible so as not to waste time, while still giving a decent insight into how the person works. (A much better insight than a traditional interview.) Again, this isn't novel, nor is it the only way to do things, but I think it does demonstrate to prospective hires that we've thought this stuff through, and are committed to building an excellent team. I would hope to see something comparable from any hiring team, but I believe it is especially important for remote teams because good communication and effective processes are that much more important without the face to face crutch to fall back on.

Anyway, congrats on heading in this direction, and putting thought into the kind of company you'd like to work for. Remote work can be fantastic; These days I would never want to work any other way.

</comment><comment><USER46> I started a consulting company about 6 years ago, worked on site with a few clients, and eventually they just didnt mind me not being there as long as the work got done. So now I have complete autonomy to come and go as I please.

I usually spend at least one week in the office because I like the routine and my gym is right there, but 75% time is spent working from other places.

Moral of the story: If you consistently deliver, I dont see why this should be a problem, as long as you dont want to work for a big corporation (FB, GOOG, etc)

</comment><comment><USER47> I had a profile lurking at Upwork.com, and while the platform itself is "race to the bottom", there are quality clients and good freelancers there too. I have been on both hiring and freelancing end of the table.

I ended up working for 2 years for same client full-time. Best job I ever had, and 100% remote.

So my advice, create yourself a good profile at upwork.com and who knows what may happen. In my case, client found me, I was not looking for anything serious in there.

</comment><comment><USER48> One easy thing I've found was to simply charge less. if you substract all your expenses - commute, office, lunch and coffee money, you can get away with charging a lot less. That way you can target a wider range of roles (roles that would pay too little for onsite work) and clients can justify your remote demands - they pay less than for onsite work.

</comment><comment><USER49> You might find this interview with data scientist Tim Hopper interesting. He works remotely and comments on tools his company uses to enable remote work.

[http://computationalimagination.com/interview_tim_hopper.php](http://computationalimagination.com/interview_tim_hopper.php)

</comment><comment><USER50> I may suggest a different route which may be more difficult, but will allow you infinite freedom. Create a small product that you can rent for 100 to 500 to 1000 to companies in your field.

</comment><comment><USER51> As a "forever globbetrotting" remote worker, I wanted to share some thoughts about it with you.

First thing first: do NOT ask yourself what a company can do for you (remote ok or not), showcase yourself and what YOU can do for a company. Here is what I mean: I've been working two years in a company which is definitely not remote friendly. I wasn't even thinking about working remotely, but life is full of surprises. I'm now (remote) fullstack lead developer of that exact same company, having 2 offices with developers spread over the world. I participate meetings, answer my phone line as if I were with all of them. We all admit I'm way more productive at work, some (including my boss) saying I may be paying an Asian guy to be "answering every time they need me". It's not about convincing each historical company to be remote friendly, it's about these companies fit the market (as they always do to keep on making money) if they want to keep on hiring most talented professionals!

If you know your stuff, you are the lucky guy. Find the job YOU love, and find it where it is. Convince them you are the guy, be opened to spend one or two weeks with your team few times per year, wherever it is, and be clear that your teammates timezone is the one (yes, you may have to be online for a meeting at the middle of the night, but the week-end after while your colleagues will be somewhere fun not that far, you will be at Niagara Falls, visiting Dubai, or sailing a lagoon in the Indian Ocean). Then just do it, you will rock it, both of you being happy with it. And do not fear realizing you work better in an office with teammates.

Having to keep a budget while travelling, I would definitely NOT recommend to be freelancer without some recurring work from multiple well-known clients (who really pays). This is NOT something to treat lightly. No money: nothing good for you, and your family. Clients do NOT contact you just because you say you are good and your website is awesome (I've been running two companies for 10 years before, I promise I know my stuff). Consider it thoroughly with your wife, even if she makes enough money for the whole family. Many (but not all) freelancer testimonies are fakes or pure dreams, it's not rare digging around you will find them always staying in Asia because it's inexpensive and they do not make enough money to get elsewhere!

Last words, regarding freelancer stuff or nomadism, keep in mind this is getting huge nowadays, and becoming a business for a lot of people who just think about making money from you with fancy website you may need (or not). I'm pretty sure you will easily find links (if not some on this thread already). Just be conscious about what it really helps you to. Having "a community" to answer questions is free as you can see ;)

In a train from Aveiro to Porto, Portugal, I wish you fame and fortune for your career! But fortune may be enough ;)

</comment><comment><USER52> The information security industry has a large remote workforce

</comment><comment><USER53> Check out nomadlist.com

</comment><comment><USER54> I think everything boils down to finding an actual demand for your skill set. As long as some organization or an investor has a real problem to solve and you could convince them that you really have the ability and necessary training and experience, then it doesn't really matter how do you work and from where. You could always frame a contract not for hourly basis but on completion of the prototype, milestones, whatever you like.

Basically, you should imagine yourself as a specialized company doing sub- contracting in ML.

Finding a real demand and securing a contract is much harder than doing actual coding and modeling. There are literally thousands of guys who are smart enough to apply ML, especially now, when it became mainstream.

PhD is, of course, a huge advantage in the world of pointy haired bosses, HR and paper pushers. With it you, probably, are looking for a very high hourly rate instead of subcontracts. In this you probably would fail, because people who are willing to pay high hourly wages needed certain rituals to be performed publicly in return.

</comment><comment><USER55> I'm actually on the lookout to recruit Machine Learning PhDs, specifically to work remotely, either on a temp fixed time or more permanent contractor basis. :) How can I best reach you to pitch you what I had in mind?

<comment><USER56> Post a reply to this month's "Who's Hiring?" and be sure to mark it as REMOTE [https://news.ycombinator.com/item?id=12846216](https://news.ycombinator.com/item?id=12846216)</comment></comment>


Extraterm. A cross platform terminal enumlator - <AUTHOR> http://extraterm.org/ <comment><USER2> It would be quite good if this is something like VSCode/Atom extension. But as a standalone application, well, ehem, electron, ~70Mb.

For more electron hate and terminal: [https://news.ycombinator.com/item?id=16900941](https://news.ycombinator.com/item?id=16900941)

Terminals I prefer over this:

[https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty) [https://github.com/liamg/aminal](https://github.com/liamg/aminal) [https://sw.kovidgoyal.net/kitty/](https://sw.kovidgoyal.net/kitty/)

<comment><AUTHOR> I've actually never understood these arguments as they're often times made. Can many (all) Electron apps be made much more efficiently in other ways? Sure, but so what? As a fact by itself, why should I care? It's a meaningless factoid and only in specific contexts does it matter a whit.

If an Electron application: 1) Provides valuable services to the user; and 2) provides those services sufficiently well enought that the user isn't troubled by the experience (or even enjoys the experience)... anything else is just noise. In some contexts, that memory issue matters, but not nearly all.

I'm finding Extraterm working relatively well so far. Seems to be performing where I want and providing a good terminal experience. It's taking a metric shit-ton of RAM from what I can tell compared to what I might expect, but... I've got RAM to burn, so it doesn't phase me in the least, I mean I don't earn interest or anything by saving that RAM so as long as that's the only ill... I'm doing pretty good. And if I want to tackle the most egregious consumers of resources, there are other, worse violators in that department... like Firefox taking an order of magnitude more RAM just to show the Hacker News tab that I'm editing in.

Of the terminals that you list, Alacritty looks interesting and I've been following a bit, and the other two are non-starters for me as I need cross- platform tools (Windows and Linux specifically).

Anyway, like most things in (professionally competent) technology, most things are good or bad only within certain contexts and use cases. Over generalization amongst practitioners tends to be a larger and more present sin than applications taking more RAM than some would like.

</comment></comment><comment><USER3> rxvt is still doing a damn fine job, and it doesn't require me to load a browser engine to interact with the shell...</comment>


Rethinking Web Browsers and Bookmarking - <AUTHOR> http://azer.bike/journal/rethinking-web-browsers-and-bookmarking/ <comment><USER2> Outside of being restricted to the browser, isn't this very similar to what is offered by Launchbar and Alfred?</comment>


Go: Best Practices for Production Enviroments - <AUTHOR> http://peter.bourgon.org/go-in-production/ <comment> grey-area What an interesting article, thanks for the writeup.

Are you using Docker for containers?

As a language neophyte I found this far more persuasive than arguments over emergent behaviour[1], because it talks about actual practice, as opposed to talking in abstractions (which rarely leads to fruitful discussion). The attraction of Go to me is in its commitment to simplicity, at the expense of some power or terseness it becomes easy to read, easy to extend, and hard to use to create monstrous complexity.

It feels like an improved C rather than building on the traditions of C++ say.

The package system, import system, composition and no inheritance, and extensive use of interfaces all encourage simplicity above all.

Composition - it's harder to create huge taxonomies which all depend on a common root.

Packaging - encourages very simple small components rather than huge frameworks which are hard or even impossible to understand all at once or separate into components. Godep[2] looks interesting here, thanks for the link.

Interfaces - similar to many other languages, but without the boilerplate of declarations (this sort of decision is where controversies start - what some see as boilerplate others see as important contracts, same goes for header files).

It is of course missing a few things which would be nice, but nothing should stop people trying it out today - if you value simplicity above all, Golang will probably appeal.

1\. [https://news.ycombinator.com/item?id=7653164](https://news.ycombinator.com/item?id=7653164)

2\. [https://github.com/tools/godep](https://github.com/tools/godep)

<comment><USER2> Go's simplicity didn't stop me from ending up with a messy, bloated and monolithic project on my first try, but static typing and good test coverage makes refactoring relatively painless.

<comment><USER3> I reckon there is no language that can prevent a bloated and messy code base. Avoiding that comes from both understanding the solution and how to write the solution with the language.

<comment><USER4> Indeed- languages without bloated and messy codebases are languages without serious users.

</comment></comment></comment></comment><comment><USER5> Nice article. As for keeping stable dependencies while remaining go get compliant - I opted for a slightly simpler solution. We fork dependencies to our internal git server (gitlab in this case, sometimes we just keep our stable fork on github), and go get them from there in the build process.

It's not much different, in that it still requires rewriting the internal imports of the libraries, but it doesn't require copying of files or working with git submodules, and provides the same stability.

I think godep certainly looks promising and I have it in my TODO to try it out, but working with forks for the relatively small codebase we have is enough for now.

</comment><comment><USER6> "Dependency management! Whee!" indeed.

I totally share the author's feelings that fetching master to do deployments is pretty rough for repeatability. Vendoring fixes the core repeatability problem, but leaves a lot of other questions. What if I want to use this library in several projects without essentially forking it for each one? What if I want to reuse two of _my_ libraries in other project, and they both vendored the same things? And so on.

I use git submodules for golang source dependencies with reasonable success. I also asked myself "What if I need this to be backwards compatible with `go get` semantics?" and found it's hackable: create a dir in your project which you'll add to your $GOPATH, add git submodules there with fully-qualified dir names matching their public urls (i.e. `myproject/.gopath/github.com/whoever/whatever/`), and to tie it off make a symlink from your own project's fully-qualified dir name back up to your repo root.

With that symlink, your own project has the same package names regardless of whether the code is being referenced internally to that project, via the public go-get'able urls, or via being submoduled in another project. Nobody's left out.

Example here [https://github.com/polydawn/pogo/commit/c6fac440c99c00c2db65...](https://github.com/polydawn/pogo/commit/c6fac440c99c00c2db6501140308cd10d0abbbe4) (though I've since switched to putting the symlinks in a .gopath dir, as that seems more popular).

Submodules can introduce complexity to a project if inserted into the middle of a project where abstraction layers aren't finished yet (all the complaints about merging being totally undefined are true). But when a relatively stable library API is either already existing or a firm intention, submodules stay pretty well out of the way in normal development and can actually cross over to helpful by drawing attention to when you should think twice about API shifts. (Also, it might be worth mentioning git's CLI for submodules has gotten radically better in the last few releases.)

It's certainly not the only way to do things, and if you're happy with other solutions like vendoring, by all means carry on (godep is great too, as the article mentions; it doesn't vendor, and still gets you a hash for precision and integrity of your deps)... I just thought it was interesting that it's possible without any special tools.

<comment><USER7> While I have in general sworn off java, and is rather enamoured by clojure's lein build tool -- I enjoyed the recent post (that was on hn as well):

[http://blog.paralleluniverse.co/2014/05/01/modern- java/](http://blog.paralleluniverse.co/2014/05/01/modern-java/)

It does appear grails manage to expose many of the good parts of Ivy/Maven while keeping build-files reasonably sane -- and crucially it appears to offer a pretty solid story in terms of "predictable future deployment" (can I restore a service in two years and deploy it on a contemporary system?).

</comment></comment><comment><USER8> I really like Go, and have been getting into it quite a bit. It's powerful, quick, and fits in nicely as a "native code" utility language, which I dig. However, the first thing the OP talks about, $GOPATH, really fricken annoys me. I know that's sort of silly, but hey.

Are there any good fixes for this at all? What other ways of tackling the dev env are there for Go?

<comment><USER9> Use the symlinks, Luke.

My $GOPATH is in a standard place: $HOME/.local/share/go (aka $XDG_DATA_HOME/go) and all my projects (whatever language it is) live in $HOME/dev.

I use github for all my projects, so the public path for my go projects would be $GOPATH/src/github.com/rakoo/petproject. So all I have to do is

        $ cd $GOPATH/src/github.com/rakoo
        $ ln -s ~/dev/petproject petproject

and everything works flawlessly. I get to keep using my ~/dev dir for all my projects, and the Go environment is well defined and works as expected.

You do have to do this once for each project you start, but that should scale quite well.

TL;DR: Your projects don't need to _be_ in $GOPATH; they only need to be _accessible_ from $GOPATH

<comment><USER8> Ah hah! I wish I could give you more than just an upvote, as that's awesome, and I really wish I'd thought of it first. I'll give it a try, thanks very much!

</comment></comment></comment><comment><USER10> Vendoring is the way to go, but it done in a very awkward way here. I find it is better to just fork the repos you depend on and reference your fork. This makes it very easy to update them from upstream and eliminates any need for third party code in your repo.

Using the command line args is great for programs with small configs, but we find good old INIs and JSON to work better for large complex configs.

I think the deploy step outlined should be running the unit tests with the race detector enabled.

<comment><USER11> Since an import cannot reference a specific tag or commit, even with forking you're exposed to the situation where a team member may update the fork and break the project. Keeping dependency information external to the project is a bad idea.

So with forking, you still have to reference a "vendor" path, as described in the linked article. You could use Git submodules or Git subtrees, or something homegrown, all of which add complexity and are not ideal.

</comment></comment><comment><USER12> This is a great article. I have also been vendorizing my dependencies. I recently have been bit by projects that I rely on (config parsers, things of that nature [and for a couple of my projects, I have too much config for using command line flags]) moving or doing silly things. The old code works fine but now it is a pain to setup a new dev environment because I have to clone from a different repo than its import path is from and check out the appropriate commits.

To solve these problems I have started an experimental thing and I would love some feedback on it. I am calling it `gopkgr` and the idea to have a thing that will let you make nice tarball packages and install them.[1] Eventually, we could have something like godoc host version-ed packages. I want to be cross compatible with `go get` but I also want to support more general situations.

For instance, right now it is really difficult to write polyglot go systems. In my research, I have a system that is go, java and python to tie things together. Super annoying to have such a polyglot system but I have different needs and each ecosystem offers the path of least resistance on each one of those needs. With the current go situation is not possible to create a re- usable package for the go code which is usable by other projects without breaking it out of the repo (which doesn't really make sense in this case).

In anycase, I don't want to solve dependency management with gopkgr. I want to solve packaging dependencies for repeatable builds without having to worry about code moving from this source code host to that source code host. (eg. google code to github or vice versa) So if you have good ideas in this regard. Let me know about them.

[1] [https://github.com/timtadh/gopkgr](https://github.com/timtadh/gopkgr)

<comment><USER13> How is this different from godep? [https://github.com/tools/godep](https://github.com/tools/godep)

<comment><USER12> I aim to do _packaging_ (putting things in tarballs). Godep is trying to solve the harder problem of creating metadata and systems to say what versions of libraries to (transitively) depend on. I actually want to utilize the Godep stuff to solve the dependency management problem for the packaging portion.

You can think of what I am trying to make as a language specific version of %.debs or %.rpms. Combined with proper dependency management, hosting, code signing and verification we could build a language specific apt-get. This is what python's pip is like. There are a lot of tricky problems between where go is at today and apt-get. Especially if we want to be resistant to things like evilgrade.[1]

[1] [http://www.infobyte.com.ar/down/isr-evilgrade- Readme.txt](http://www.infobyte.com.ar/down/isr-evilgrade-Readme.txt)

</comment></comment></comment><comment> why-el Nice article. For those of you working on a SOA project, can I have some feedback on how people manage data sources? For instance, I am in the process of breaking up a monolithic application into small services, but the problem is that most of these services rely on the same data (For instance a search service and an autocomplete service will work with the same data). What are you strategies to deal with this? I mean, is it simply a matter of relying on the same database? How about models built on top of this database and their tests?

<comment><USER14> Nothing wrong with two services using the same data source. If data locality is a concern, deploy both services alongside one another.

Or you could place the data behind an API. It would speak HTTP/Thrift/whatever and would be solely responsible for handling the data. Front the API with a cache if latency becomes an issue.

For your specific example, consider pushing data to autocomplete and search instead of having them pull.

<comment> why-el Interesting. Are you aware of any high profile examples of this architecture?

For my own case, search and autocomplete use the same modeled data, but autocomplete for instance runs lots of precalculations on this data, so the data behind an API is not really a choice.

</comment></comment></comment><comment><USER15> _That means tabs for indentation, and spaces for alignment._

Not a go user (yet), but this one caught my attention as being a little ugly. I'm a fan of only using spaces.

<comment><USER16> Tabs are just customizable whitespace. If you like 6 space indents and I like 2 space, we can both be happy if it's tabs, and just configure our editors the way we like. With gofmt, there's no danger of mixing spaces and tabs (not that it's actually dangerous, since whitespace isn't important in go).

</comment></comment><comment><USER17> Excellent article, thanks for sharing! I wish I could attend Gophercon but I'm way down here in South America.

What book would you recommend for someone who wants to learn about Go practices and professional tips? I'm not interested in a reference book that teaches me how to loop, but a book that teaches me applicable knowledge in a bit more advanced subjects.

I'm aiming to make Go my primary workhorse language.

</comment><comment><USER18> Why the advice against `make` and `new`? Is it only because make sometimes requires you to know sizes in advance?

<comment><USER19> It's less noisy just to take the address of an automatic variable, like foo := &Bar{}</comment></comment>


The only CSS3 gradient generator with Opera & IE9 support (via SVG) - <AUTHOR> http://www.display-inline.fr/projects/css-gradient/

<comment><AUTHOR> A lot of CSS3 gradient generators exist with support for CSS3 gradients (Webkit, Mozilla). Some of them also support IE4–8 "filter" gradients [1]. But this is the first I've seen that includes SVG generation, which works in IE9 (where filters won't, if you are using IE9 rendering mode) as well as Opera. Not to mention, SVG is a finalized format, but CSS3 gradients are still in flux.

[1]: Previously on HN: <http://news.ycombinator.com/item?id=1767265></comment>


The Information Apocalypse Is Already Here, and Reality Is Losing - <AUTHOR> https://www.buzzfeednews.com/craigsilverman/coronavirus-information-apocalypse <comment><USER2> "It may seem a ridiculous idea, but the only way to fight the plague is with decency." ~Ed Begley Jr.

Same goes for disinformation pandemic, eh?

Fidelity to reality becomes exponentially more valuable as time goes on. We might rediscover _honor_.</comment>


Natty: a natural language date parser in Java - <AUTHOR> http://natty.joestelmach.com/

<comment><USER2> OK, it can't parse:

      The day before Sunday week
      The day before Sunday
      Next Sunday
      Sunday

Now, you may have tried putting in "Sunday" and it worked, but it didn't when I tried it.

I had a leading space.

Going to the "Let use know" link takes me to a github issues reporting page. I stared at it for about 30 seconds, then decided life's too short and I'd report my findings here.

So I've made it parse some of the above, it appears that there we odd spaces, but I can't retrieve the exact cases now, so I can't really make a sensible bug report.

But it still doesn't parse "The day before Sunday week," nor "The day before a week on Sunday." It also doesn't parse "26-05-2010," the usual UK data format, but you probably knew that.

Is your test data set available?

<comment><AUTHOR> Thanks for the feedback.

I'll admit to the amateur mistake of not handling leading white space (that's now fixed on the master branch.)

It looks like the only example from your list that couldn't be parsed is "The day before Sunday week". Forgive my ignorance, but I've never seen 'week' used in that context here in the US. If you'd be willing to describe the proper use, I'll look at implementing it.

As for the UK format, please see the issue I created here: <http://github.com/joestelmach/natty/issues#issue/3>, and lend some advice if you'd like.

The test set is available here: [http://github.com/joestelmach/natty/blob/master/src/test/gun...](http://github.com/joestelmach/natty/blob/master/src/test/gunit/DateParser.testsuite)

<comment><USER2> In the UK and Australia, "Sunday week" would be taken to mean one week after the Sunday after today. Also phrased as "a week on Sunday."

I have use for the library, but cannot use Java. It's nice to know that such a solution exists, and perhaps I can push towards an equivalent for my contexts.

Thanks for your response.

</comment></comment></comment><comment><USER3> Nice, joestelmach! We're using JChronic (<https://jchronic.dev.java.net/>) at DotSpots right now for this stuff internally. I'd love to switch to something better maintained.

FWIW, Ruby's chronic contains some date formats that this doesn't seem to support right now ('5 minutes ago'):

<http://chronic.rubyforge.org/>

Aside: I'd really like to see a publicly-available set of natural language date test cases shared across these projects.

<comment><AUTHOR> Thanks for the feedback.

The chronic project was actually the original motivation behind natty. I think the chronic project is great, but I believe the grammar-based, AST approach is the way to go for long-term maintainability.

Implementing relative times has been on my list of things to do (in addition to recurrence.) I created a feature request here: <http://github.com/joestelmach/natty/issues#issue/4>, so feel free to list any time formats you'd like to see implemented.

I agree that a generic list of test cases would be nice. Any thoughts on how such a list should be published?

<comment><USER4> A list that can be used for interoperability tests would be great, even across languages. For example, Perl has DateTime::Format::Natural that provides this functionality. There's a list of supported inputs at [http://search.cpan.org/dist/DateTime-Format- Natural/lib/Date...](http://search.cpan.org/dist/DateTime-Format- Natural/lib/DateTime/Format/Natural/Lang/EN.pm) .

I guess such a list of test-cases could simply be a JSON file containing the input strings plus an output specification. The options for output would only be explicit datetimes, datetimes relative to the now, or timespans.</comment></comment></comment>


Show HN: Voxel Space – terrain rendering in less than 20 lines of code - s-macke https://github.com/s-macke/VoxelSpace <comment><AUTHOR> It just blows my mind that my laptop has less issues rendering this than it does generating my react-native build :D I love 90's era programming, the thought going into things to squeeze every last ounce of performance is just beautiful.

<comment> s-macke I wonder, how they generated the landscapes. They are so small (1024x1024), but it takes a while to recognize the repetition. The game Comanche needed 4MB of RAM.</comment></comment>


Rent in Vegas, Commute to San Francisco, Save $1,124 a Month - <AUTHOR> http://www.realtor.com/news/trends/rent-in-vegas-commute-to-san-fran-save-money/ <comment><USER2> Where is she finding these $35 total flights between Vegas and SFO?</comment>


Ubuntu installed on my IBM BladeCenter E in my apartment - <AUTHOR> http://picasaweb.google.com/shae.erisson/UbuntuOnMyBladeCenter#

<comment><USER2> There was a time when getting Linux running on a standard PC/laptop brough much joy ...

Now its all about running Linux on beefy servers, obscure embedded devices, cell phones, clusters, and well, you name it.

Who knows what technology we'll have 10 years down the road, but lets hope that the "YEAH!! I GOT LINUX TO WORK ON IT!!!!!" feeling never goes away :)

<comment><USER3> it's only a matter of time until i can write cron jobs on my rice cooker. then i will truly know happiness.

</comment></comment><comment><USER4> Is it just me ... or does "IBM BladeCenter E" sound much more impressive than the little box in the pictures ...?

<comment><AUTHOR> You'd be a lot more impressed if you stood behind it when the fans spin up. And if you got to see all the lights in the house dim when it starts to draw power. Or if you had to carry ~140 pounds of the chassis and two blades.

Or if you had a shell account on the HS21 blade with two quad core Xeons and 16gb of ram :-)

<comment><USER5> yeah, bladecenters are awesome.

</comment></comment></comment><comment><USER6> The QS20 looks interesting, sad to hear it didn't work for you.

Do you have any good links for developing for it? The little bit of Googling I did for QS20/21s just found glossy type info and few concrete examples of things that you can do with it.

<comment><USER7> The QS20 uses the same Cell SDK as the PS3. It probably also runs the same Yellow Dog distro. It's kind of pointless though since it's so expensive and difficult to program.

<comment><AUTHOR> I got seven QS20s for $700, so I was happy. Older Cell blades are more affordable than you might think.</comment></comment></comment>


Fans angry over 'missing' iPhone 7 headphone socket - <AUTHOR> http://www.bbc.co.uk/news/technology-36606220 <comment><USER2> When did summarising twitter opinions about a tech industry rumour become news??</comment>


Results from Assembly Summer 2011 - <AUTHOR> http://www.assembly.org/summer11/news/results

<comment><USER2> I love the demoscene, I wish it were a much bigger phenomenon than it is (especially outside of Northern Europe).

That being said, one of the constraints on _really_ getting why a demo is impressive is being able to appreciate what's going on. It's like understanding wines or beers or fine cheeses. You need to have a large base knowledge going in to get _why_ the winning demo is unbelievably amazing.

Most people, even very technically or artistically inclined people don't get it. They think it's an interesting art project or something. But really understanding why it's impressive compared to say <http://www.youtube.com/watch?v=9oXRP5OM6tA> requires a pretty deep understanding of the capabilities of modern computing.

<comment><USER3> Nonsense. I'm neither technically nor artistically top of the bill, I have no good clue about the "capabilities of modern computing", but still I've been an active demoscener (producing and consuming) for years. To say I don't understand why these things are impressive is, well, a bit weird.

For me, it's simply (and only) freeing yourself of the limits of <your favourite animation tool> and replacing that by the limits of your programming skill and your computer's raw power.

This differs per person, but in the winning Assembly demo shown at the OP, for instance, some people may find the sea-particle-system impressive for its technological prowess; i'm more impressed by how code, not keyframes, was used to choose where which wave flows.

This also implies that I can find the same awe in watching Processing sketches, even though those hardly ever push the hardware limits.

</comment></comment><comment><USER4> Download: [http://pouet.net/prod.php?which=57446&howmanycomments=25...](http://pouet.net/prod.php?which=57446&howmanycomments=25&page=0) (43mb)

Edit: Second place is a 64k demo: <http://www.youtube.com/watch?v=69Xjc7eklxE>

<comment><USER5> What does it mean for it to be a 64k demo. That all the code required to produce the video fits in 64k? Can they call external libraries? How do they talk to graphics hardware?

<comment><USER6> The executable file may not exceed 65536 bytes. No external data files are allowed. Any and all external libraries available on the compo machine may be used, including OpenGL/DirectX. The full specs of the compo machine, including software configuration are announced beforehand. In general, you can pretty much expect a stock win7 machine with modern hardware.

In 64k competition, data such as textures, models, samples/synth, etc. are either precomputed or generated on the fly. Most groups have their own tools or use tools available in the community.

</comment></comment></comment><comment><USER7> Having seen the demo scene from its inception in the late eighties I find it fascinating that after all these years we are close to saturating our analog senses with this digitally created content. 32bit pixels saturated color perception, compressed music maxed out hearing and we are now pretty close with form and structure.

There are still nuances that we can keep chasing but looking at the big picture we are pretty close to generating a comprehensive audio visual experience.

</comment><comment><USER8> These demos are always so impressive.

I am always a bit disappointed though that such creativity is always restricted to demo comps while we are stuck with relatively mundane, static visuals in games.

<comment><USER9> The creativity is in no way restricted to the demoscene - just more conspicuous. Creating games involves a different set of constraints, and there are plenty of examples of ingenuity & creativity to be found there.

In fact, many game programmers are also involved in the demoscene; For instance, the guys who created Max Payne were a part of the infamous Future Crew.

<comment><USER8> Really? I don't remember the part in Max Payne where I got to drive a car made out of squiggly light that turned into a rhinoceros.

<comment><USER9> Nor did you get to _drive_ it in the demo - it's the scripted composition that makes it interesting. It works brilliantly as a demo, but I suspect the novelty of driving the morphing squigglemobile in the demoverse would wear off pretty fast.

And once you do start incorporating other elements like AI, level geometry, physics, etc to make things interesting, you'll no longer have the luxury of allocating all your computational resources for graphical eyecandy.

</comment></comment></comment></comment><comment><AUTHOR> At first I somehow missed this archive page, it's linked from the page, but just in case: <http://archive.assembly.org/2011>

</comment><comment><USER10> The winning one is really impressive from an artistic point of view imho.

</comment><comment><USER11> Greatest demo ever, IMO, was Future Crew's Second Reality. That utterly blew my mind in 1993. <http://www.youtube.com/watch?v=8G_aUxbbqWU>

<comment><USER12> Wow check out 1993 - we have come soooo far:

<http://www.youtube.com/watch?v=LIIBRr31DIU>

Listen to those hard drives!

Netscape Navigator didn't come out until over a year later (December 1994) and IE 1.0 another year after that. Wow.

<comment><USER13> Cool I've never seen this before. Ah ScreamTracker 3 I used to listen to mods in that all the time.

Does anyone know if there is a current good site that reviews/indexes good new mod/scene releases besides index sites like pouet.net or scene.org?

<comment><USER14> Modarchive is probably the place you're looking for: <http://modarchive.org/>

</comment></comment></comment></comment><comment><USER15> I've always thought of 'Codename Chinadoll' as an unheralded beauty.

It seemed unusual in 1999 and still stands out stylistically today.

It featured some really nice 2-d elements, nods to print media.

Its poor placement in competition, difficulty running on a wide variety of hardware, and general lack of direction was mostly due to the sad circumstance of its main coder dying before it was completed.

<http://www.youtube.com/watch?v=4q0xv2123Ic>

</comment><comment><USER15> It's ironic that the main method for sharing our favorite demos today is a youtube link.

</comment><comment><USER16> I can watch these for just the music. The amount of work into these few kilobytes is just amazing.

<comment><USER15> <http://scene.org/>

</comment></comment><comment><USER17> I wonder if the guys used a functional programming language.

<comment><USER18> Functions? Luxury! When I was a wee lad, we had naught but JMP. And we were _happy_ to have it.

Actually, most demos are written in C these days, I believe.</comment></comment>