Absolutely this. When facing a tough problem it’s a great tactic to write out what you’re trying to solve and how you plan to solve it in prose-style English.
I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.
I’d also add that a very prototype that you throw away also helps line up your thoughts.
The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code
I agree with this to a large extent. A new codebase in the latest Java/whatever can be OK. But most of the time I feel like it's dealing with the same bad code, with just a smattering of nice syntax on top.
I started learning Perl in 2007; after it was no longer popular, but also around the time that the principles/practices that became 'Modern Perl' were becoming popular in the community.
I think there is a difference between the two though. Java was always a language which required a lot of ceremony and typing to get anything done at all. Perl was always focused on expressivity. Modern Perl was a case of learning from past mistakes and consciously avoiding some of the more egregious code the language easily afforded. Modern Java is more a case of Java playing catch-up to the more expressive languages out there.
One is applying constraints on your coding style, the other is trying to lift constraints. Both are trying to reach some middle point.
But! I agree that no company writes purely 'Modern Perl' - you will have to deal with some terrifying code at some point.
So. I agree with the concept of the 'Modern X' fallacy, but I would say that dealing with non-modern code is pretty normal, and people who are OK putting up with the pre-modern code may be some of your best employees. I suffer from rewrite-it-all syndrome myself sometimes, but it's something I try to avoid. Code that frustrates me, isn't necessarily bad.
(If it helps contextually, I'm - at heart - a Clojure programmer.)
Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview. It's a bad signal.
Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.
There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.
Not a direct response, but expanding my thoughts slightly:
1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.
2. Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. I'd hate being pigeon-holed just because I happen to know one thing.
3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.
That's only superficially the same. There's questions and there's "let's work through this" questions. The latter are awesome when explicitly stated as such and can be (should be?) as hard as you want to make them - I find I learn from them whatever happens.
Love it! One of my favourite bad interview questions. I got asked this in an interview ~5 years ago. My response was to look shocked... Pause. Then ask: "What do you mean? What detail do you need? DNS? SYN / ACK? HTTP?"
At the point I started talking about syn/acks they just cut me off and moved on to the next question.
Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question.
I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
That's a great book. I've just started reading I Am A Strange Loop by Hofstadter and it's promising.
Also by Hofstadter: Le Ton beau de Marot was a good read.
GEB is the big one, but if you like his style - probably worth checking out some of the others. Best to get print books for this particular author though.
Re. "Continuously Deliver them to the Docker Registry". Is this focussed on open projects going to the public registry? Or will you provide a private one / integrate with services like quay.io, etc.?
Possibly more interesting... start the video from the beginning and they're talking about software patents. The same points were being brought up then as now.
Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
> The consensus in the community right now is to not get carried away with macros and DSLs. Even if your library provides a DSL, it should be based on a functional API that is mostly usable without macros.
Yup. But what people say and what people do is often not the same thing :).
Thanks for this; pretty much the response I was expecting but very well said.
My opinion is that functions that take quoted code do actually do the 99% job of macros pretty well. I also think creating completely new syntactic forms is fantastic for a solo project; but not so great when working in a team. So I'm left thinking what difference does it actually make. My general feeling is that I tend to write macros in Clojure just to deal with someone else's macros; i.e. macros 'layer' whereas functions compose.*
Incidentally, I've been curious about but never looked at Erlang's parse transforms because they have - in my mind at least - a big 'here be dragons' sign above them. Enough articles have warned me off to make me nervous. Would love to know more though.
Kinda fair - I meant "homoiconic" in the loose sense of having macros that can manipulate expressions as data and which has mechanisms such as quote/unquote to do so.
That's what many people see as the reason for homoiconicity after all. I put it in quotes, but maybe I should have said something about how languages can support sophisticated Lisp-like meta-programming without being a Lisp at all.
Nonetheless, as I'm still learning (aren't we all?), I would love to hear what a truly homoiconic language has above something like Elixir with its quote, unquote and unquote_splicing. By truly homoiconic I mean that AST is equivalent to the written form.
EDIT: I now realise you're not only rvirding, but that you wrote Lisp Flavoured Erlang https://github.com/rvirding/lfe so therefore (I hope) are in an even better position to educate!
100% agreed. I've been looking at Elixir occasionally for a year or so... It's getting better and better. It certainly takes a lot from Clojure, but with a real Erlang / OTP twist. (It also recognises that "homoiconicity" doesn't always mean lisp). Elixir's Design Goals are stated here for those who've missed them: http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/
I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.
I’d also add that a very prototype that you throw away also helps line up your thoughts.
The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code