This is a nicely succinct expression of what I intuit to be almost a universal rule of creating/designing/making.
It’s related to what I think of as “coherency” and I’m often surprised at how long it can take.
The most recent example is that I was writing up some technical feedback for a reviewer of a product I develop.
My first draft was several pages worth of dense prose. I realized I needed to simplify, otherwise it would overwhelm the reader. I worked on it for several hours, and in the end I had it down to about 4-5 paragraphs.
So it took me five hours to write what looks like a simple, straightforward email!
I’m a music producer by trade, and the principal is very much at work. To create a successful recording requires getting into the small details of the sounds, and working with them, whether your tools are complex or simple.
As someone who earns their living writing articles and web copy for brands, this frustrates me no end. I'm often asked why I charge so much more for web copy than a blog article, when a blog article is often 1000 words plus and web copy might be 200 words or fewer (sometimes just a couple of sentences with a strapline).
The answer is that I can write a competent blog article about as fast as I can type. Decent web copy that boils down the essential benefits and features of a product and expresses them concisely and compellingly takes much much longer to get right.
Timely! I'm on "hiatus" and producing music again after a 10 year break. It's been months of learning. With the new tools I can go so much deeper, so I am. If you want repeatable processes you have to focus on tools and organization. I've integrated github, google docs, Reaper, and bunches of VSTs and I'm just barely starting to see a good organizational approach. This is 1 year later!
I would love to see a more in-depth description of this process you've gone through, in a blog or reddit post or discussion thread somewhere.
Like many others, I've been playing with digital recording tools off & on since the 90s as a total amateur (wanted to be in a 'cool band' since middle school, still do), and while I know there are a thousand great guides out there, I always seem to find them overwhelming/paralyzing.
Admittedly, I probably don't travel in the right circles for it, but the github and google docs aspects in particular sound like something I haven't read as much about musically inclined people doing before.
I was thinking along similar lines the other day. I was thinking about whether I've actually improved as a software developer over my career. It occurred to me that most of the languages and frameworks I use are either less than a few years old, or have been changed or reinvented in substantial ways. As such, not much of the declarative knowledge from my early career is of much use. But have my skills improved?
I came to conclusion that my ability to code on the micro scale, e.g. at the level of an individual method or algorithm, probably stopped improving after 2-3 years of professional experience. I think you could take the 24-year-old me, ask him to work on a narrow problem, and he'd do about as well as I would now.
But where the 24-year-old me struggled a lot was at the macro scale. He didn't know how to compose those individual pieces into a cohesive hole, and instead fell back on a handful of patterns like singletons. I remember horrible days trying to unravel my own code and figure out how component X was going to communicate with component Y, and the result was often a mess.
I think this macro-scale ability really does improve continuously over time, as you are exposed to more and better patterns for integrating components and managing dependencies.
This is not true of me. Even on the micro scale, I'm much better than I was at 24. I write far fewer bugs. And I write code that communicates intent much better.
This reminds me of the PHD in the office, who was hired because of some mathematical related skill they specialize in, is never getting their hands dirty. They are off somewhere looking smart and protecting their allure, while us grunts are keeping the lights on. Broad stereotype here, but it is what I have experienced.
To be very honest, being on Google searching constantly has been the most important skill. In this face paced IT environment, if you stay too long becoming an expert on something, it's replacement is coming right around the corner.... even within the same framework. As I was finally getting a hang off Spring 4 and Spring Boot 1.x, then comes Spring 5 and Spring Boot 2 with their new WebFlux architecture.
A lot of the awesome I see people smarter than me doing, is not getting bogged down in nitty gritty but instead thinking about how to DTRT. Then, when they do it, the apparent effort is low: you've discounted the french metric tonne of thinking time that led up to it.
Equally, they should get their hands a little dirty. Best is to be a great chef but spend some time with the bottle washers relating to being a dishpig. Nobody really likes Gordon Ramsay as much as the chefs who invest in staff development.
"In this face paced IT environment, if you stay too long becoming an expert on something, it's replacement is coming right around the corner..."
Depends what the value adding function is. I work in a field (essentially CAD) where getting anything done takes years at best and if a technology does not have an estimated lifespan of at least a decade we don't invest in it.
Excellent point. Even though a lot of things change, there is a lot that remains the same or is done better with previous years of experience. CAD being a great example.
I think the massive amount of churn in the web world is the exception rather than the rule. If you learned C programming 40 years ago it would still be relevant today. Even Android is almost 10 years old now.
If you learned Ada, Modula-2, Pascal, or BASIC, though, it might not be so relevant. COBOL, FORTRAN, Smalltalk, and Perl 5 are somewhat useful, akin to, maybe, jQuery in the web world.
You can use Perl instead of PHP, Python or Ruby. They all have their strengths and weaknesses but overall they are very similar when it comes to usefulness.
Point taken, but I feel all those languages had good runs. Modula-2 might have had less commercial success but still holds some intellectual interest. I sort of got sick of the web treadmill in 2013 as it felt like "learn a new toolkit every 18 months" and am primarily interested in something with longevity in that niche.
Sure, but jQuery from ten years ago is still jQuery. What iteration is Angular on now? Its doesn't have the churn that more recent web frameworks have.
This reminds me of the PHD in the office, who was hired because of some mathematical related skill they specialize in, is never getting their hands dirty.
You know the adage "Work smart not hard"? That's what you get a PhD for.
You're like the hospital janitor complaining that the doctor never wipes the floor. He's just off somewhere "looking smart".
... do you realise how ridiculous this sounds?
Let me say that I get your point of view: I know of the existence of smart and educated people who are lazy, presumptious, have a superiority complex, talk down on everyone and/or are fakes.
Do you understand my point of view though? Are you aware that people exist who are less educated people and who can't grasp that valuable complex things exist which requiring specialized knowledge, and that those less educated people being unaware of the existence of such things automatically and wrongly assume that their specialists are fakes?
The thesis of the article is that most companies are looking for doctors when they actually just run a cleaning service.
This is not a great analogy. "Algorithmic wizardry" and "organizational skills" are two distinct skill sets, and it's perfectly possible to be great at the former but lousy at the latter.
Since we're all throwing around anecdotes, I k ow both PhDs and long-time industry experts - gun to my head, one of them has to solve a problem or I die, I'm gonna choose the industry expert even if it's in the PhD guys field. Academic honours are very over-rated
That is not nearly accurate analogy. Note that doctors in hospital do more then just looking smart.
And know multiple people who are like he described: generally keep aura of looking smart are are good in few selected areas and generally don't really do much work. And they always get absurd amount of benefit of doubt the same way you do here. Meanwhile anyone who criticize them is assumed to be stupid hospital janitor who don't get that they are the ones who do real work.
And know, they do not do "valuable complex things" nobody else cant grasps on the project. They talk about complex things around water cooler to impress people.
And yes I do know people who do complex things too.
Right, so we both know both types. But the person I was responding to either doesn't, or chose to omit one to try and make a point about it.
> That is not nearly accurate analogy. Note that doctors in hospital do more then just looking smart.
That's precesily my point. Doctors in hospital do more than just looking smart, even though janitors may or may not realise it. It's really an excellent analogy.
I have been a janitor (or pretty much that) during my MD studies, then I have been a nurse, then a doctor, then a programmer.
I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own).
In the IT field it's different though. Every junior is absolutely sure they are better than their team lead (been there, done that, also been the team lead). Every QA thinks that programmers are lazy brats. Every PM too. Every programmer thinks QAs and PMs are stupid and can't grok their (programmers') work (which, so far I think that it's indeed true (maybe not the stupid part, but the 'can't' part), and that's why the industry suffers).
It’s a bigger divide when we go across teams. Most programmers distinctly look down upon sysadmins and as a sysadmin and developer I really have to say that the sheer number of former blue collar workers that became sysadmins compared to developers does not help the perception. But more importantly, a lot of engineers have a sheer disdain for sales as if they don’t work hard and the same goes back even further where engineering students look down often on most liberal arts students (never mind that the liberal arts and business students are the ones that they’ll be working for probably statistically speaking).
> I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own).
More than once I've heard staff (not janitors though) talking depreciatively about doctors (e.g. "he thinks he knows everything", "he said X but my uncle says Y").
I think if you read what I wrote a bit more charitably you'll see that my point wasn't really about janitors. I used them figuratively to comment on OP's attitude that seemed like the terrible combination that is confidence and ignorance.
I absolutely agree with your comments. I just joined in to give my 2 cents with some real experience and to give more nuance to the discussion. I do agree that medical and IT fields are different (and that's what I tried to explain in my original comment)
> I didn't know a janitor who thought that nurses or doctors didn't do valuable work (greatly more valuable than their own).
Much harder, no doubt. More valuable though… a good portion of that value comes from having a clean hospital to begin with.
(Not that I am not talking about market value, which is obviously much lower than that of doctors, thanks to the larger supply of janitors, and how much cheaper it is to train them.)
Not trying to dismiss your thoughts, but I never met a janitor who believed something like this. They knew perfectly well that they are easily replaceable, that their work is easy etc. It might be because of culture/location of course - Eastern Europe in my case. Also, have in mind that the hospitals I worked in are quite different from what you imagine when you say "a hospital" and especially "a clean hospital" :D. One of the reasons I switched careers and locations.
I agree wholeheartedly with your points. Though I must say I am not talking about the hospital industry, I am talking about IT.... where we developers are the doctors. I also think that these PHD's can add immense value, they are in fact very smart and educated.
I'll tell you one anecdote, when big data was starting to bubble up, there were PHD's that were hired at two firms I worked at. Eventually in the long run big data was done, but it was not from their efforts. It was the grunts.
I work on math-heavy engineering software where it can take a month to learn how some clever algorithm works and I'd say organizing the code is still equally as important as that. I've thrown away big clever algorithms when I found libraries that did it for me and did it better than I could.
I mean, CRUD doesn't have to be simple. It can get complexity from the underlying data, or dealing with 100 million users at once, or it having to return results FAST.
Just because you don't have to write some novel algorithm doesn't mean you're not solving hard problems.
I think the parent wanted to say that their problems are rather tedious than hard.
I'm currently in a very similar situation - a project in which we have a table of records, two of which are special in a certain, business-related way, but need to be presented along with the others, so to get around this we place "ifs" here and there - a lot of them.
It's a generally simple project that has been turned into something overly complicated because somebody lacked the foresight to design the architecture better.
What I meant is that with a decent database design, you shouldn't need to much code to get things done (using Django as I am used to).
Instead I am jumping from file to file, trying to work out what is going on, what all the seemingly unnecessary code is doing. It can be both tedious and difficult just to get data between the database and a webpage.
I want to rewrite a lot of it, but I understand that working, tested code is actually worth quite a lot, and there may be functionality that i haven't understood yet.
I never understand why it is looked down upon so much here on HN. Sure anyone can write a crappy insecure PHP for checking a few hundred records. But building a secure maintainable performant application takes some knowledge.
I think he's agreeing with you on the overarching theme. If I'm reading his comment correctly, he's saying that despite him writing math heavy stuff, organizational skills are super important and as important as raw algorithmic skills.
we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
This is from the preface of SICP[1] which taught me that abstraction is the most important concept of programming (and computer science?). Do you need to know how sqrt() has been implemented to being able to use it? no. A programmer shall first have a good knowledge of the abstraction techniques. He shall know how, when, and the cost to use them. Then, if you are illiterate when it come to algorithm design and analysis, it shall not be a problem because replacing a bad algorithm/implementation by another would be easy due to the correct application of abstraction. "The cleaner and nicer the program, the faster it's going to run. And if it doesn't, it'll be easy to make it fast." — Joshua Bloch
This is exactly my experience too. When I started working as a SW developer, I expected to use a lot of the clever algorithms I had studied at university. That didn't happen. Instead, the tricky problem was having lots and lots of simple features aggregated together - complexity from aggregation.
These were my top 2 surprises when I started working as a programmer:
> But it’s hard to have the patience to wrap your head around a disorganized mess that you don’t care about. Only if the disorganized mess is your responsibility, something that means more to you than a case study, can you wrap your head around it and appreciate improvements.
This really hit home for me. I personally find it very difficult to get emotionally invested and therefore effective when working on a codebase that I don't personally like. But that's not very professional, so I tend to phone it in when in that situation, at the expense of really using my talents or dedication. But I know that other professional coders do better than me and somehow find a way to be very interested or invested in things they don't care about, perhaps because for many coders, the code itself is enough to warrant the personal interest, and less so what the actual code is used for? If I don't have a big-picture appreciation of a project, I don't enjoy the small stuff either. Perhaps that means I'm in the wrong profession.
I have found out that the only thing that motivates me is thinking about the people that will use what i code. Either the users find it useful and enjoyable or the company find it profitable. I dont see any reason to work on something where i cannot see my role in contributing to these things.
The tough truth is that you need to be able to do both, or your skillset will never be complete. If you specialise in algorithms, you might never be able to put a bunch of them together to build a system that works and does something interesting. If you focus on architecture but never understand how to read and implement algorithms and how to evaluate them, you will always be limited in what your systems can achieve and how well they work.
Additionally, most of us are limited in what we can learn in a lifetime. Talent is far from the primary limitation (most people will be average in terms of innate ability; my guess). Far more important is the time available to study and learn new skills and the motivation to do it. Then there are issues of personal preference: if you just love algorithms, you will tend to focus on them, if you love building systems, etc.
There is something that doesn't ring completely true about this. While I agree coding is not about coming up with some ninja recursive one line function that solves all the problems, reducing it to a simple matter of organization is not quite right either. Yes it is about organization, but there is a component of wizardry too. It takes a lot of intelligence, skill, experience and talent to be able to identify and model the fundamental relationships between all the parts in the simplest possible way. It's what separates seniors from juniors. The top guys do the tricky work of architecting and modeling the system, while the juniors fill it in until enough new information is revealed for the seniors to improve/change/update it as needed.
> The top guys do the tricky work of architecting and modeling the system, while the juniors fill it in until enough new information is revealed for the seniors to improve/change/update it as needed.
If that is how it works, I did not really experienced it. In one place where they attempted this, senior ended completely out of touch with his architecture problems - because it was only juniors experiencing them and never him. In big corporations, architect does super uber high level and negotiations.
Big refactoring and architectural changes were done by seniors and require experience, of course. But that is only part of what senior does, a lot of if is using existing architecture. Also, juniors can grow into such senior only by taking on larger and larger tasks - you don't get there by filling small boxes without doing own decisions, mistakes and living with them.
The biggest problems, especially in larger projects, are organizational one. As in, algorithms part is what is often done by juniors, who often actually can do them well being just out of school and being trained in them lately. And also who have bigger uninterrupted chunks of time then seniors.
There are algorithms for sorting with known properties. There are no algorithms for problem analysis - just a lot of tradition (e.g. “refactoring”) which is hand-wavey even when it’s done well, and actually adds complexity when done badly.
The kind of problem segmentation => simplest solution we’re talking about isn’t even mentioned on most CS courses, and certainly isn’t taught in any useful way - possibly because it hasn’t been researched or understood.
You need to ask questions that let them show off their full understanding of a system. People without organization skills will focus on one area and not explain the whole.
My favorite is to have someone explain to me what happens when a browser makes a HTTP request to a web URL, which has <insert framework and DB here>. Network guys will tell you all about the request and response, web developers will focus on the front end, devOps will tell you how all the pieces communicate, etc. My expectation is for someone to at least be able to give a high level of all those things, while also having detailed knowledge of some specific areas... and seeing how they choose to answer such an open-ended question tells you quite a bit about where their focus and attention lies.
Personally, I would answer that question by telling you how the HTTP protocol works because, in my mind, that's what you're asking for. If you're going to ask that question, I think you need to be more clear about what you're looking for. I don't think there is any value in interviewers being intentionally vague in order to test if a candidate can guess what they're thinking.
You presume I want a specific answer -- I don't. I want to know how they think about a system. In your case, you laser-focused in on 'HTTP'. OK, that tells me a bit about how you think. If you were to say the question was too vague, that also would tell me how you think. If you were to ask for more clarification, that might be a really good first response. There is no right or wrong answer. Interviewers don't always seek specific answers. I'd argue that the best interviewers never seek specific answers, they ask questions that help us learn who you are.
It's basically "what big projects have you done a ton of work on". Have them design something not straight forward or posted online in front of you as well.
I did not read that into the original comment, but if the OP's suggestion is to rid the interview process of dumbass brainteasers and whiteboard questions, then I'm all for it.
- describe a failure in your career and how it went from there
all this is for the interviewer and the interviewee to get to know each other each other and see if the candidate is a good fit for the company culture and values. If the recruitment lets in a narcissist or toxic person it will poison the well.
These would be perfect questions, if candidates didn't lie.
They do. All the time. More often than you'd think about something as trivial as "can you actually write code".
And so, you'll need to demonstrate your skills. Find a better way with an extremely low false positive rate, and you can make a fortune consulting and implementing that. It's not like anybody likes doing these interviews.
You don't need to ask "really hard Algorithm puzzles" to figure out whether they can actually write code. You can ask normally hard or even simple algorithm and have them implement it. If your company does object oriented, you can also ask them basic patterns. If you do functional, have them do little bit of that.
It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part.
That being said, asking logical puzzles is fine when you are hiring juniors you expect to train. The question with them is "is this kid smart enough to understand what I will teach" not "does this kid already knows everything". However even there, really hard algorithm is not something I would go for.
If you don't ask "really hard" questions[1], candidates instead complain because "any child can solve this" and feel not taken seriously. Somebody will always complain.
"asking logical puzzles is fine"
No. NO. NO. That's the thing that isn't fine, because solving a logic puzzle relies on one critical insight. It's rolling the dice.
What you want is a question that has multiple answers, that's dirt easy, and where you can ramp up the difficulty to the moon if the candidate breezes through. These questions are hard to find, but they exist. They require investing some thought, so they're unfortunately not asked too often. But they work. (For small values of work. There is no good interview process)
[1] Somewhat hard. It's solvable in 45 minutes, it's not that hard.
> It is the "really hard" part that is criticized here, not the "algorithm" or "code something" part.
Really? That's not how I read it. And when I asked OP, that's not how he responded. The examples of questions that he said he would ask had been stripped of any algorithm-related questions, or any questions that involve coding.
I'm talking about serpix. When I asked him "if you don't thik that algorithm questions should be asked, then what should?" he replied with a list of pointless questions.
Then you said "it's really hard bit that's being criticized here, not the algorithm bit."
No, it's the algorithm bit that serpix was originally criticizing, as evidenced by the fact that when he replied to me he didn't include algorithm questions from the list of things that he would ask.
When I interview people, I ask them to describe a project they worked on. I ask them questions about the project and see if they're able to talk intelligently about the architecture. I talk to them about what I'm working on, so they'll know if it is something they want to do, and ask them questions about my project to see if they can talk about them intelligently. During this process, I get a feel for their technical abilities, how they like to work, and who they are as a person. I can tell if someone has skills without resorting to silly puzzles, obscure CS questions, or several hours of playing "Guess what I'm thinking."
I also don't find any value in testing "How someone solves a problem," since people solve things differently. I have no guarantee that my way is the best, so why would I reject someone else just because their brain works differently than mine does?
Does this promo piece add anything to the original blog post that it feeds on? I didn't notice anything. Why not link the blog instead?
http://prog21.dadgum.com/177.html
I don't understand this! Math is a super set of algorithmic wizardry and if you include heuristics in algorithmic wizardry (why would you not?),isn't organizational skills a part of the Algorithmic Wizardry? So he's saying that knowing all skills in the subset is better than knowing all the skills in the set? And that's just the headline
> isn't organizational skills a part of the Algorithmic Wizardry
No, because organizational skill involves also following (not required for algorithmic wizardry):
* Solving same situation consistently the same way.
* Differentiating between important for maintenance and unimportant.
* Ability to plan - think in advance about how much time people need to answer your questions and giving them time. Realize that other people are not available at your whim.
* Negotiation, understanding what other people mean and being able to express what you mean the way others understand.
* Being able to do also boring parts, not just fun stuff. Keeping up work even if nobody controls you.
* Being able to know what is "good enough". Organize work the way that most important parts are done first, don't just follow what is fun.
* Writing the code the way other people not just understand it. So that tests are possible and actually write tests.
There are many people, algorithmic wizards or not, who cant do the above. That is why agile have standups and jira tasks with max 0.5 day size by the way, because way too many people never finish tasks they are assigned to without being checked on every day.
Organization is a mathematical and algorithmic problem regardless of the context. And if you think people go to school so that they mug up algorithms, you're missing the point of school. You go to school to learn how to problem-solve, how to model problems mathematically and incidentally become aware of a repo of solved problems which may help you in your own problem solving adventures.
This is what I read in this article. The author has a problem with people thinking that rote-learnt algorithms is the best thing ever, and proceeds to say nope a stash of the most subjective heuristics to produce 'good code' is wayyyy better. All in all the way I see it, the author is proposing to supplant a shittty misconception with a bs idea that is nice short term solution but a complete disaster in the long term which has inculcated into this idea that programming is an Art and not a discipline.
Math is a clean room where you don't need to worry about the concrete representation. Often the details of the representation and how they connect are more to do with human psychology (keeping things understandable) than with algorithmic heuristics.
I sincerely think that the minute you stop thinking that Math cannot be applied to a problem solving situation or Math is too fancy/theoretical, the Tower of Babylon type problems starts
It’s related to what I think of as “coherency” and I’m often surprised at how long it can take.
The most recent example is that I was writing up some technical feedback for a reviewer of a product I develop.
My first draft was several pages worth of dense prose. I realized I needed to simplify, otherwise it would overwhelm the reader. I worked on it for several hours, and in the end I had it down to about 4-5 paragraphs.
So it took me five hours to write what looks like a simple, straightforward email!
I’m a music producer by trade, and the principal is very much at work. To create a successful recording requires getting into the small details of the sounds, and working with them, whether your tools are complex or simple.