InfoWorld reports that F# is becoming ever more popular. It has risen from 69th to 12th in the Tiobe Programming Community Index.
I’ve been writing F# code for over 3 years and I get the appeal – there are some algorithms that are so much easier to implement in F# than in C++ (particularly when they can be neatly expressed with the additional data structures that F# provides, like discriminated unions).
Filed under Programming
This book was pretty ordinary, which made me wonder how often you can accurately identify a rotten book within the first chapter? If you have a good prediction rate, you could save valuable reading time for better books. A give-away from this book was the amount of the story that was told via dialogue. Whole chapters without any narrative. And another flaw was the lack of emotional depth – much is made of a “Famous Day” that Kay and Simon spent together – so why not, you know, actually put it in the book. It needn’t even be at the start – tuck it in further down the book – but don’t leave it out completely!
Now, I think I would have given up on Free Fire too early, because that turned out to be pretty good. On the other hand, this book was poor and the only reason it escaped two stars was due to a much improved final couple of chapters.
Filed under Book Review, Musing
Nice analysis of the Apple security bug on Slate.
Preventing bugs like these is one of the biggest challenges of software engineering, and this incident should make it pretty damn clear why. A single extra line of code compromised the security of millions and millions, and no one caught it for more than a year.
The obvious question is: why no unit tests?
Filed under Programming
HereIsTheCity reports that the mystery behind a Twitter account posting comments heard in elevators at Goldman Sachs has been resolved.
He said he deliberately never said in any of his tweets that he worked for the firm. “This was never about me as a person,” he said. “It wasn’t about a firm. The stories aren’t Goldman Sachs in particular. It was about the culture in general.”
Here are some example tweets from @GSElevator:
#1: I just want to be rich enough to not be motivated by money.
If someone asks you a question and you don’t know the answer, belittle them. It’s better to be an asshole than stupid.
If there’s a hot chick behind me at the ATM, I’ll always leave my receipt in the machine so she can see my balance.
Filed under Finance
Plenty of good ideas here from Jeff Atwood. I love the passion he shows for his new venture:
Have your team and yourself start using that minimum viable product, every day, all day long. This is way more than mere software development: it’s your whole life. If you aren’t living in the software you’re building, each day, every day, all day … things are inevitably going to end in tears for everyone involved.
Now, need a customer service mindset for this approach, and a band of dedicated, cross-discipline engineers prepared to roll up their sleeves and get things done. But if you have that spirit and belief, the project can succeed.
The only thing I’ve ever seen work is getting down deep and dirty in the trenches with your users, communicating with them and cultivating relationships. That’s how you suss out the rare 10% of community feedback that is amazing and transformative. That’s how you build a community that gives a damn about what you’re doing – by caring enough to truly listen to them and making changes they care about.
Filed under Programming, Soft skills
Another in the Lincoln Rhyme/Amelia Sachs series from Jeffery Deaver – this one is pretty good and hints at the dangers for society with the growth of corporations that store massive amounts of data about private citizens.
Filed under Book Review
I don’t usually read biographies, but this excellent biography of Alan Turing was given to me as a gift and I found it fascinating. There are plenty of plaudits for the treatment Andrew Hodges has given his subject and I agree he’s done a first class job. Even more so if you read the author’s notes at the end of the book and appreciate just how little material was freely available and the personal hardships the author entailed in order to write the book. His sources were the biography written by Turing’s mother and the academic papers/records available. Subsequent to that, Hodges interviewed many of the main players in Turing’s life in order to reveal much of the character of the man as well as to fill in the gaps in his life history.
For me, Turing was famous for the Universal Turing Machine and the Turing Test – it’s interesting to learn that he also touched other areas of pure mathematics and science. The technical details on his approach to writing computer software are just as relevant – given that he was involved in the earliest computers in the 1950’s and the biography was written in the 1980’s, it’s great to know that Turing exhorted the earliest programmers to factor their code into sub-routines and to test their software!
Another lesson to learn from the biography was that, whilst Turing was happy to work individually and largely avoided self-promotion, that approach limited his opportunities. If he had been more savvy in this regard and been more amenable to building working relationships, who knows how much more he would have achieved.
Filed under Book Review
This is another Harry Bosch novel from Michael Connelly. I liked some of the back story where Bosch duels with his new statistics-led boss and has to get creative in order to continue with the investigations that matter to him. I found the main plot rather tenuous and didn’t buy into it – not one of Connelly’s best.
Filed under Book Review
This paper by Dijkstra was linked from a discussion on ArsTechnica about system design. It’s amazing that many of his high-level points remain true today, despite being published in 1968 – I’ve picked out a few below:
Focus:
Production speed is severely degraded if one works with half time people, who have other obligations as well. This is as least a factor of four, probably it is worse. The people themselves lose time and energy in switching over, the group as a whole loses decision speed as discussions, when needed, have often to be postponed until all people concerned are available.
Star developers:
The intellectual level needed for system design is in general grossly underestimated. I am more than ever convinced that this type of work is just difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expenses.
Unit testing:
It seems the designer’s responsibility to construct his mechanism in such a way —i.e. so highly structured— that at each stage of the testing procedure the number of relevant test cases is so small that he can try them all and that what is being tested is so perspicuous that it is clear that he has not overlooked a situation.
I’d add to the list that it’s vital to spread knowledge within a team to maintain productivity and avoid one person being silo’d to a specialist skill and becoming a bottle neck. Instead, find out how to pull the source code out of the repository, how to build and test it – and start making small changes yourself as a learning exercise.
Filed under Programming, Soft skills
ArsTechnica hosts a number of discussions on software development, and arguably none more important than layering.
Understanding one thing at a time is easier than understanding two things that only make sense when used together … Rules of thumb such as “No cyclical dependencies” or “Dependencies must only reach down one level” simply capture the practically achievable limit of the fundamental idea that one thing at a time is easier to understand than two things.
Whilst interfaces and abstractions buy you immunity to change for a given class/component, a layered architecture buys you the flexibility to swap out an entire layer of technology. That’s something that can happen surprisingly frequently in the corporate world – need to replace MFC with Silverlight then with WFP then with HTML5? No problem if your architecture is layered such that none of the business models need to be re-released for the change. Similarly if a game-changing Hadoop solution is rolled out for your data storage – a well layered architecture can remain impervious. But mix up all that logic so that models source data and user interfaces call into low-level analytics – you’ve got a migration nightmare on your hands.
Filed under Programming
musingstudio 