shawnps

I started learning Japanese around 8 years ago, and I've never been a fan of saying it's "the most difficult language to learn." It's like learning anything else, if you enjoy learning it and are motivated enough, you'll get better. Also I'm surprised when people assume the grammar is difficult - to me, the "flexible grammatical structures" as mentioned in the article are a good thing because it gives you more leeway to make "mistakes."

If you're learning Japanese in school, or even if you're learning it on your own, I recommend the Genki I and Genki II books, and the corresponding workbooks. If you really enjoy it and want to come to Japan to use your newly acquired language skills, I'm confident that after getting through those 2 books you'll have enough Japanese to get by and you can have fun wandering around, reading signs, chatting with strangers, etc. Don't be discouraged by people saying that Japanese is so difficult to learn.

Edit: also, I hope this comment didn't come off as too negative. I think it's great that Duolingo is doing this, and if it gets more people to enjoy learning Japanese then that's fantastic.

I know many people in tech from non-US countries who went through a lot of trouble to get hired on H1B visas. The power of the US passport (for engineers) is the ability to work legally in the US.

I've heard good things about this: http://smartairfilters.com/en which is really just a fan with a HEPA filter attached to it.

Certainly the first time I've seen "otsukaresama" described as "beautiful". It's like something you say to your coworkers when you pass them in the hallway.

Pretty neat, but the first thing I looked for was how to open a file in Python and it wasn't there. I'm guessing it's because the "File" column only displays methods on the file object, and open is a built-in function. I can see how this might be useful when context-switching between different programming languages.

A long time ago I was interviewing with Facebook. They told me exactly what to expect from the process. I was actually shocked that they were giving away so much information. I studied for the interview and did very well in the first half, and then horribly the second half. Overall I enjoyed it because of how honest they were.

Not a startup, but I was going to shut Go Report Card (http://goreportcard.com/) down because I didn't want to pay for it myself anymore, and I reached out to Digital Ocean and was given some credits to keep it running. Thanks.

Definitely take a look at Go. If criticism on HN is what you're concerned about, I can tell you that when I started writing Go ~3 years ago it got a lot more criticism on HN than it does now. I've used it as my primary language since then and it's a fun language.

I enjoy it, but only if I'm treated with respect, not micro-managed, and trusted to do my job. Ironically when managers set deadlines and add process, it demotivates me and the code ends up shipping later. The silver lining, however, is that I learn what not to do if I decide to start my own company (I have a note on my PC called, "Mistakes from previous companies that you shouldn’t make"). So in general, even if I'm unhappy at a job, I try to consider it a learning experience and move on to the next thing.

Edit: I should add that working remotely has been absolutely fantastic and adds to why I enjoy being a programmer. I feel lucky to work in a profession that allows this amount of flexibility.

We have lots of unit tests and a fair amount of integration tests. There is a staging environment as well, and I personally do a bit of manual testing whenever I push just to be sure nothing is catastrophically broken.

Commits to master don't get automatically deployed, and we deploy manually to staging then to production. I like the idea of automatically deploying to staging. It takes one more step out of the process.

When I worked at #2 there were 0 tests, which I believe is why management was often so afraid to deploy. Of course things are going to break if there are no tests. It took me a year to convince them to add unit tests, but we got there eventually.

I've worked with a few different branching styles, including:

1. Feature branches that get merged into master via PR in GitHub

2. Sprint branch, bug fix branch, and master

3. Developers push directly to master (or if they really need a code review, push to a branch)

So far I prefer 3 the most, then 1, and I hope I never have to do 2 again. 3 is fastest, and we write a lot of Go so many of the comments I would have made on a Python PR for example aren't necessary.

I've worked remotely for the past year and it has by far been the most productive year of my career as a software engineer. I'm not sure if I will ever want to work in an office again. In my experience, when working in an office environment, people will interrupt you while you're in the middle of writing code. You'll be asked to attend meetings that are ultimately pointless. You'll feel bad about wanting to work from home or from a cafe. The amount of freedom and the feeling of finally being treated like a responsible adult that comes with working remotely is addictive to someone like me who just wants to code all day.

This is not idiomatic Go code and in my experience not many people will do this. New Go programmers who ask for help with a piece of code that ignores the error are told immediately to check the error. And experienced Go programmers simply do not ignore the error.

There is a pretty good book that covers some of this called Moonwalking with Einstein:

http://www.goodreads.com/book/show/6346975-moonwalking-with-...

I picked it up because it was on a list of books that Bill Gates had read one summer:

http://www.gatesnotes.com/About-Bill-Gates/Books-I-Read-This...

The part about core rope memory was pretty interesting. Star charts and other bits of data were actually woven into a form of read-only memory via loom:

https://youtu.be/xY45YE7ggng?t=1155

https://en.wikipedia.org/wiki/Core_rope_memory

Ran it through an app I maintain, Go Report Card, and it got an A+ grade: http://goreportcard.com/report/renstrom/shortuuid

I'm actually pretty surprised, as I do this quite often and it's rare that something gets 100% across the board on the first try. Not that it's necessarily difficult, but I find people normally don't use all 3 of "gofmt -s", "golint", and "go vet". Anyway, nicely done.

I personally wouldn't call it excessive. It's more like set it once and forget about it. And it's something that basically all professional Go developers do, along the same lines of how everyone runs gofmt.

I'm surprised to see the author mention not being able to compile when there are unused imports. Editor plugins that call goimports have solved this problem for a long time now. For example, I use vim-go (https://github.com/fatih/vim-go), and if I remove the only line of code that references the "fmt" package, the "fmt" import line at the top of the file will automatically be removed.

Edit: Here is the reasoning on the FAQ behind code with unused imports not compiling: https://golang.org/doc/faq#unused_variables_and_imports

Brad Fitzpatrick, a prominent Go developer and Google engineer actually gave a talk covering some of this at GoCon Tokyo last year: http://talks.golang.org/2014/gocon-tokyo.slide

Skip to slide 32 for examples of different tasks for which Go is proving to be efficient.

If you liked this you might also find Rick Hudson's talk on GC improvements in Go 1.5 interesting:

https://www.youtube.com/watch?v=aiv1JOfMjm0

https://talks.golang.org/2015/go-gc.pdf

Meanwhile, in Tokyo:

http://www.jreast.co.jp/e/info/map_a4ol.pdf

http://www.tokyometro.jp/en/subwaymap/pdf/routemap_en.pdf

How about:

"learn to program go"

"learn to write go code"

"first go program"

"go hello world"

I don't understand why people find it so hard to search for Go-related things, and would love to see some example bad searches.

Here are some that do work:

"string formatting go"

"regex go"

"convert string to int go"

"web server go"

"json go"

"smtp client go"

"http request go"

Edit: oh, and can't forget "learn go" :)

This is the site I usually check:

http://aqicn.org/city/beijing/

Also, if I needed it, I'd probably build one of these:

http://smartairfilters.com/en.html

Interestingly, a search for "retard" in code on GitHub yields over 200,000 results:

https://github.com/search?q=retard&type=Code&utf8=%E2%9C%93

Not sure what made this particular case different.

It's in GitHub's TOS that they maintain the ability to remove content they find offensive. So they asked a user to remove something that GitHub found offensive.

As well as an "office lobby" photo: http://s3.amazonaws.com/o.oculuscdn.com/v/test/social/avatar...

I attended Northeastern University where PLT Scheme (now Racket) was the first programming language I ever learned in a classroom. Matthias Felleisen, the second poster in that thread, is a professor at NU and co-author of How to Design Programs:

http://www.ccs.neu.edu/home/matthias/HtDP2e/

I recommend this book for anyone interested in learning more about Racket.

I agree. I sent a tweet to the author requesting it, hopefully he sees it: https://twitter.com/shawnps/status/615780187800629248

Unfortunately headphones will not prevent people from tapping you on your shoulder and interrupting your flow.

I'm recently working remotely and I find that I'm a lot more productive in this environment than I was in open-plan offices. I do however miss the social aspect of easily being able to grab lunch with a couple of coworkers.