henrik_w

70 ms·

751.
Microservices for Greenfield?(samnewman.io)
4 points by henrik_w 12y ago|0 comments
752.
Chrome plugin spying on Swedes' surfing habits(translate.google.se)
1 points by henrik_w 12y ago|0 comments
753.
by henrik_w 12y ago
Yes! I love that quote - so true. Linus has the same opinion: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." [1] I actually refered to this when discussing switching f
754.
by henrik_w 12y ago
"The trick wasn't really so much the coding but coming up with how it organizes the data." I think this really is the key to understanding git as well. When you understand the git data structures, git makes sense. Otherwise,
755.
How Coursera Competes for the Best Talent(firstround.com)
81 points by henrik_w 12y ago|31 comments
756.
by henrik_w 12y ago
Ned Batchelder has a good page with "Kindling projects" http://nedbatchelder.com/text/kindling.html
757.
Real Software Engineering [video](youtube.com)
3 points by henrik_w 12y ago|0 comments
758.
by henrik_w 12y ago
It's not clear to me how you prove that you did the work for the course. As far as I can tell with Coursera, all it takes is for you to input the correct answers in order to pass (i.e. you may have found the answers online, had a frien
759.
by henrik_w 12y ago
In some cases it works (beyond the multiple choice quizzes). In the algorithm courses I took, you have to implement a algorithm, and input a number that proves the implementation is correct. For example, on a graph with, say, 500,000 nodes,
760.
by henrik_w 12y ago
I like MOOCs, but I am using them as continuing education while working, not as a replacement for college. For that purpose, it works quite well [1]. However, one problem is when you study a subject and get a bit stuck (currently taking Pri
761.
by henrik_w 12y ago
In my opinion [1], TDD is best suited for algorithmic logic, but doesn't really give any benefits for coordinating code. This is explained well in "Selective Unit Testing – Costs and Benefits" http://blog.stevensan
762.
by henrik_w 12y ago
:-)
763.
by henrik_w 12y ago
"I highlighted a ton of things". I haven't read Founders at Work, but I really enjoyed Coders at Work by Peter Seibel in the same series. I had the same feeling with that book - I scribbled down a lot of notes on interesting
764.
The Canonization of St.Steve of Cupertino(qz.com)
4 points by henrik_w 12y ago|0 comments
765.
The Dangerous Effects of Reading(blog.davidtate.org)
103 points by henrik_w 12y ago|24 comments
766.
by henrik_w 12y ago
Current (still on front page) HN thread on pros and cons of working from home: https://news.ycombinator.com/item?id=9231541
767.
Exploratory Testing 3.0(satisfice.com)
1 points by henrik_w 12y ago|0 comments
768.
Lean in, push out(economist.com)
2 points by henrik_w 12y ago|0 comments
769.
“There Shall Be No Bugs” Is a Dangerous Pipe Dream(spin.atomicobject.com)
2 points by henrik_w 12y ago|0 comments
770.
by henrik_w 12y ago
There may not be anything you can do. In order to grow, sometimes it's just time to move on. Learn a new system and language, work with new people etc. Basically I think it's healthy to change jobs once in a while. Personally I ha
771.
by henrik_w 12y ago
I don't agree that programming expertise is fragile. There is a kernel of knowledge that transcends language and syntax, and that is by far the bigger part of "programming knowledge", much more important than knowing specific
772.
by henrik_w 12y ago
Code that glues together and orchestrate interactions between other code units etc. It's hard to test because of all the dependencies, but the actions it performs are not very complicated, so not worth the effort of unit testing. For m
773.
by henrik_w 12y ago
Agreed. I think Jay touches on this when talking about how you don't need to aim for 100% unit test coverage. It's also what I mean by testing algorithmic code (where the pay off from the effort is large), versus testing coordinat
774.
by henrik_w 12y ago
I like Jay's comments about how tests are wasted if you don't know exactly what you want, and just try out different things (because then you need to change/delete the tests when you end up changing your code). As for common
775.
by henrik_w 12y ago
My take on the opposite - what makes a good programmer: http://henrikwarne.com/2014/06/30/what-makes-a-good-programm...
776.
by henrik_w 12y ago
Sure, you can ask companies to give their new hires books to read and pointers on what to learn. However, it's even better if the new hires already read books to improve their craft. On their own initiative. There is still plenty of
777.
How Simple Questions Lead to Great Innovations(linkedin.com)
1 points by henrik_w 12y ago|0 comments
778.
by henrik_w 12y ago
+1 for Clean Code. I just recently read and reviewed it: http://henrikwarne.com/2015/01/03/book-review-clean-code/
779.
Flaws in Scrum and Agile(pandastrike.com)
7 points by henrik_w 12y ago|1 comments
780.
by henrik_w 12y ago
Kevlin Henney mentions this program in his talk "Cool Code". The whole talk is really worth watching. http://www.infoq.com/presentations/Cool-Code

More ›