Well, “10x engineer” drama is all over the Internet for a week, I think. Of course, most of it ridiculous, but the main point stands - there are always ways to improve the development performance, some people managed it already some - did not. I am asking the recommendations on how to improve the performance of writing OCaml code, mostly in terms of the functional paradigm. Asking because I find myself 0.001x engineer for OCaml, which is unacceptable. Moreover, a collection of such recommendations will benefit the community.
5 Likes
We’d love to have some more contributions to this page.
1 Like
I meant the human performance, not the code performance itself.
Oh. Sorry. Do you mean best practices then? These memes tend to fly over my head.
Not the best practices overall, but a recommendations how to solve the problems with OCaml faster. How to become faster to design types, put ideas and algorithms from your head into the compiler, etc. Surely, there is something.
Most recommendations I can give aren’t specific to OCaml. They include:
- Consider the team’s productivity rather than individual contributions. Read articles or a book on software engineering management even if you don’t want to become a manager yourself.
- If you work alone, keep in mind that someone will have to take over your work at some point. If the project is a throw-away exercise, make it clear to users.
- I recommend The Effective Engineer by Edmond Lau for best practices in software engineering.
3 Likes
The Pragmatic Programmer, is a classic book recommended for beginners in software engineering in the industry. Interesting read full of practical advices.
1 Like
In my opinion, one way of being an efficient ocaml developer is to keep it simple.
Ocaml is a surprisingly good friction-less programming languages that allow you to prototype very fast. At the same time it has very advanced features that let you express some problems in very abstract/complex way.
This is a trade-off in any languages, but i think ocaml has a un-usually wide spectrum to very simple code to functor-heavy with GADT and object phantom-type code only few people can read/write.
On top of that, there are lots of brights programmers and researcher in ocaml community who write clean complex code that might make it looks like it’s easy.
My point is, sometimes complex code/feature is a good, sometimes its fun, but if you want to be efficient, then keep it as simple as possible.
5 Likes
Over my 15 years of professional programming experience, I have worked three times with
“three sigma programmers” (I don’t call them 10x).
Like, their productivity was at least three standard deviations away from the mean.
Two of them were self taught and never completed university (which made me understand that university is not for everybody, for some, it is way too slow a pace).
One of them was a complete ass hole in terms of personal relations.
One of them was leaving code behind him which was hard to maintain (very few
code factorization, overly complex). But still, I recognize he could seriously kick-start a project like putting it on a Saturn V rocket.
The only common trait I found in them is that they were always learning (reading books and practicing) and trying to improve over time.
They were all vi users, which still saddens me to this day, since I am en Emacs user. :^D
Often in open source projects, I interact with people I am pretty sure are 10x but I have never shared an office with them so I cannot be completely sure. For those ones, their common trait is that they all have a CS PhD and have spent some time at INRIA.
5 Likes
I am heavy [Neo]Vim user, this fact doesn’t really help me.
1 Like
But, you are on the right track, see! 
2 Likes
When it comes to becoming “better” at using any particular language or thought paradigm, I believe nothing beats simply putting in some effort and time to practice. You might get more results by deliberately practising in a way that pushes your boundaries, but ultimately there aren’t many shortcuts.
More generally, picking up OCaml itself is probably a good way to become 10x developer 
3 Likes
actually i want to refine my previous reply : you are not a 10x ocaml developer. I’m not a 10 times ocaml developer. Most of us are not 10times ocaml developers. Who cares ? this is fine.
In my opinion programming languages are a mean to an end. As long as you can accomplish your goals, and you can do that efficiently, you do great. Sure becoming a better dev is a good goal, that comes with practice, trial and errors. My point is, trying to become a 10times dev is the wrong goal. The good goal is to setup yourselfs programming tasks and practical problem, and try to solve them efficiently. Everytime you learn something new, it can be very techical thing like how to encode some problem in a better way, it can be very practical thing like how to write good tests for network code. But i don’t think pursuing the goal of becoming a 10times dev will get you there, i’m afraid it is only a one way trip to over complication, lack of accomplishments and in the end, lack of self esteem. This is my honest opinion on this matter.
Being a rank rookie with Ocaml and most programming topics. I find the hardest things to discover about Ocaml are the things I don’t know about Ocaml.
On a very general and high level – plan ahead, so that you don’t have to write code that you do not need. This is what makes you productive at the end of the day. How to write only the code that you need is sort of an art, which could be learned only by trial and error. Twenty years of everyday coding and lots of reading usually help (though no guarantees attached). Also, I’m always trying to read more than write. Reading others code gives a lot insight on how not to write the code. Especially, when this other guys is you from the past 
And yes, it has nothing to do with OCaml, sorry. But where OCaml helps a lot in productivity, is its robustness to changes. It means that you can write the code that you need right now and only when it becomes obvious that you need to change it, you can safely and minimally modify the code without the fear to break everything. This is why OCaml is very good for prototyping, and very often a prototype could mature to a real program.
To summarize, the more you think, the more you read, the less you write. The less you write the more productive you’re. Also, sleep a lot. When you sleep your brain is running GC and freeing RAM, so that you can be productive.
16 Likes
All Hail EViL mode in Emacs!
</off-topic>
However, the best thing I’ve learned about becoming a good developer is never stop coding, not just in one language but dang near every language you can get your hands on! Every language teaches you something different, whether that’s why (for me) static typing is awesome, or some programming patterns are better at certain things, or why OOP in general sucks (cough), etc… etc… Never stop coding lots of little projects. The amount of times I’ve written compilers in way too many languages is easily my personal best learning tool. Just find a project that uses lots of paradigms and code it in a ton of languages, you’ll learn some great things, some things that really suck and so you won’t do those again, why performance is fantastic for certain things but not all things, etc… Every language you learn helps you with every other language, don’t get stuck in just one way of programming.
1 Like
There’s an old maxim that 90% of programmer time is spent on maintenance, and only 10% on new code. [Uh, maybe I’m off on that; might be 99% vs 1% grin] Want to be 10x programmer for real? Be the person who can
(a) always find other people’s bugs faster than anybody else
and (b) both fixes bugs in ways that don’t break later, and writes code that doesn’t have bugs.
I had a chat with a (former) friend once, and we agreed that even though we’d been thru all sorts of “constructive logic”/“proofs-as-programs” stuff, all the standard blather of our Church of Lambda, we both found that the most useful bit of stuff we learned about proving programs correct, was in David Gries’ class based on his book The Science of Programming.
Basically, most programmers are unable to explain why their code is correct, or even what that would -mean-. Don’t be like them.
7 Likes
I once read the book as far as its preface, and there Prof. Gries said:
One cannot learn to write large programs effectively until one has learned to write small ones effectively.
I had also recently read Prof. Hughes’ paper “Why Functional Programming Matters”. There he said:
When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language.
To add to that, in his Milner award lecture, Dr. Xavier Leroy described the notion of a “perfect” program:
The one that does exactly what it should do, no more, no less, every time, with perfect reliability, and forever. The kind of perfection that you can get from mathematical definitions, which software is to a large extent, or from philosophical concepts.
This gave me a mental model to evaluate programs in the small, which if Gries is right, should translate to programs in the large as well, thanks to higher-order functions with which, as Hughes said, we can glue all things together.
The other mind-expanding idea I learned from the typed-functional world was through the talk Effective ML, where Yaron Minsky articulated “Making illegal states unrepresentable”. This was then expounded on for an hour by Richard Feldman in his related talk “Making impossible states impossible”. The insight has deep rewards, but it would appear trivial once you’ve practiced for a while. However, I had spent better part of a decade vaguely grasping for it and never finding it.
And with opaque types, I finally understood what encapsulation really meant, no thanks to years of immersion in object-oriented programming.
I’m much better at modelling programs today than I was three years ago. I think it is a 10x improvement. I also now know about the literature around types and PL so I can go looking for more. But without formal training in computer science, I’m finding it difficult to pick up gems from books like The Science of Programming.
However, I hope it should be possible to develop intuition without necessarily working through formal literature. Joe Armstrong said the difference between when he began programming vs then was that originally he had to write a program and keep rewriting it till it was perfect. But now he can think about it, maybe for a long time, and finally write the correct program. There just isn’t all this writing and rewriting.
That’s where I would like to go, and I’m hoping to try out modelling languages (Daphny, Alloy) as a step in this direction, but will appreciate all and any pointers forward.
5 Likes
Everything you write is true, and the people you cite are quite correct. I used to say
Types are obstructions in the maze of programming: too many of them,and there’s no way thru; too few, and there are too many dead-ends; just enough, and there’s exactly one path – to the exit.
But I didn’t mean that. For critical algorithms and protocols, modeling will never be enough: it requires proof. And for that, as I noted, Hoare-logic-style proofs seem more… effective than the constructive logic I ingested like mother’s milk, back in my academic career.
I recognize that a book like Gries’ is pretty formidable. But I would suggest that working thru all the homework problems in it would be valuable. It really is different than modeling, different than picking the right types. And I say this, as a rabid, rabid Ocaml bigot who really does believe the maxim I wrote above.
ETA: Upon re-reading, it occured to me that I didn’t give an example. So here’s one: suppose you want write a general topological-sort package for graphs, which deals with cycles, and also is able to support a programmer-specified comparison-function on nodes, so that nodes that aren’t related by the partial order are enumerated by the sort in an order consistent with the comparison function.
[An example of why that might be useful is if you’re sorting function-definitions that were written without regard to which ones reference which other ones (no “define-before-use”) and obviously if function A doesn’t mention function B (nor by any transitive chain of mentions) then you’d like these two functions to come out in the same order they went in. So you might use ( * ) as the “node-name”.]
Anyway, it’s not completely straightforward to get this right, and in the process actually -proving- that the code works as desired is useful. And I don’t quite see how better types can help with that burden.
2 Likes
For people who are already OCaml programmers, I think doing some Haskell is an interesting experience.
Maybe doing some Idris would also be an interesting experience.