henrik_w

95 ms·

931.
by henrik_w 13y ago
Reminds me of this video, from The Onion: "Google Opt Out Feature Lets Users Protect Privacy By Moving To Remote Village" http://www.theonion.com/video/google-opt-out-feature-lets-us...
932.
This Post Will Make You A More Effective Communicator In 90 Seconds(linkedin.com)
4 points by henrik_w 13y ago|0 comments
933.
by henrik_w 13y ago
A program made up of loosely coupled pieces has several advantages over one that is more monolithic. It is composable – all you have to do is put the parts together, then you have your complete program. It is easier to modify, because parts
934.
by henrik_w 13y ago
A "simpler" version is discussing the problem with your colleague in front of a whiteboard (drawing almost always seems to help). Once you've worked out how to implement it, you go off and implement it yourself.
935.
by henrik_w 13y ago
The question of time in relation to tests is interesting. If you write the code with the mindset that you should be able to test it (including time dependent behavior), you can end up with testable code without too much trouble. The key is
936.
by henrik_w 13y ago
As edw519 tweeted: (Great Process + Average People) < (Average Process + Great People)
937.
by henrik_w 13y ago
I don't agree with "making code easy to test tends to over-abstract it". The dependencies are there no matter what, but they become more obvious when you try to test the code in isolation. I think the main benefit of TDD is t
938.
by henrik_w 13y ago
Exactly. You grow software. I really like this quote (by John Gall): "A complex system that works is invariably found to have evolved from a simple system that worked."
939.
by henrik_w 13y ago
+1 for a short course. Much easier to fit in in a busy schedule.
940.
by henrik_w 13y ago
The XP book was hugely important for me. I read Kent Beck's article on Extreme Programming in IEEE Software in October 1999, and got the book as soon as it came out. For the first time I saw a methodology that reflected how I actually
941.
by henrik_w 13y ago
"Code Complete" by Steve McConnell has the best advice on naming classes, ,methods and variables that I have read (don't have the book handy here, so can't give examples right now).
942.
Who Goes to Work to Have Fun?(nytimes.com)
1 points by henrik_w 13y ago|0 comments
943.
by henrik_w 13y ago
This was also on HN not too long ago: "I Was a Warehouse Wage Slave" http://www.motherjones.com/politics/2012/02/mac-mcclelland-f...
944.
by henrik_w 13y ago
"Tracking down bugs" is a previously unsolved problem. It may not be difficult, but it also may require as much creativity as writing something new.
945.
Datensparsamkeit(martinfowler.com)
5 points by henrik_w 13y ago|0 comments
946.
by henrik_w 13y ago
You're probably thinking of the hilarious "High Frequency Dating": https://news.ycombinator.com/item?id=6773841
947.
by henrik_w 13y ago
Jokes aside, it's quite interesting to think about how close to an in-person experience this (or similar) can get you. For example body-language. I get quite animated when getting in to a technical discussion - how would that feel in t
948.
What it feels like being an iPad on a stick on wheels(labs.spotify.com)
123 points by henrik_w 13y ago|25 comments
949.
by henrik_w 13y ago
Perhaps it's worth paying for it for you? Calculate how much your time is worth, and compare to how much more productive you would be. I'm using the free version, since I'm only doing Java, but I truly think IntelliJ IDEA is
950.
by henrik_w 13y ago
On the subject of multithreading, I like this one by Ned Batchelder[1]: Some people, when confronted with a problem, think, "I know, I'll use threads," and then two they hav erpoblesms. [1]: http://nedbatchelder.co
951.
TDD, Unit Tests and the Passage of Time(henrikwarne.com)
1 points by henrik_w 13y ago|0 comments
952.
by henrik_w 13y ago
Or "A witty saying proves nothing" (Voltaire). Taking myself as an example: I like programming, and I am good at it. I don't like administration. So I don't try to become a manager, or a project manager or similar. I am
953.
by henrik_w 13y ago
Regarding luck, this was here on HN recently: "What if successful startups are just lucky?" https://news.ycombinator.com/item?id=6794612 And the top comment (by pg): All successful startups are lucky, but they&#x
954.
by henrik_w 13y ago
Yes, focus on your strengths. I like this quote: "For years I have urged managers to concentrate their efforts in areas in which they are strong and to waste as little effort as possible trying to improve the areas in which they don&#x
955.
Udacity Exploratory Data Analysis(udacity.com)
1 points by henrik_w 13y ago|0 comments
956.
by henrik_w 13y ago
I haven't used any other IDEs really, so it is possible there are even better IDEs, but the step from Emacs to IDEA was huge (but of course it was also a switch from C++ to Java). Editor-wise it's Emacs and Vim (for the past yea
957.
by henrik_w 13y ago
I've been using IntelliJ IDEA for many years (coming from C++ in EMACS), and it truly made me more productive: http://henrikwarne.com/2012/06/17/programmer-productivity-em...
958.
by henrik_w 13y ago
Here is a good article giving non-programmers 5 reasons to learn how to program: http://blog.learnstreet.com/5-reasons-you-need-to-learn-to-p... Personally, I like point 5 the best: "Programming is fun".
959.
SCIgen - An Automatic CS Paper Generator(pdos.csail.mit.edu)
3 points by henrik_w 13y ago|0 comments
960.
by henrik_w 13y ago
This reminded me of "SCIgen - An Automatic CS Paper Generator" http://pdos.csail.mit.edu/scigen/

More ›