Controversial programming opinions
programmers.blogoverflow.com
programmers.blogoverflow.com
- 1: I'd modify "Programmers who don’t code in their spare time for fun will never become as good as those that do", to be "Programmers who don't code in their spare time for fun will never be as good as they would if they did". I definitely believe coding for fun helps your skills, but I've seen too many "just-a-job" programmers code circles around others on the same teams who had side projects and kept up with the trendy languages. It's not a clear differentiator, just a data point.
- 2: Unit tests don't help you code in the same way that a safety net doesn't help you walk a tightrope: this is technically true, but not a helpful statement in reality.
- 10: Print statements are "valid" in that they often work, but when a debugger is available it's almost always the right way to go.
The author mentioned that unit tests are useful to check for broken code, but he's saying TDD doesn't actually help you write better code--that there are plenty of other ways to screw up that unit tests won't catch so the extra cost of writing them ins't worth it (in his opinion).
He's saying that it's an ineffective safety net, not worth the extra time involved setting it up.
I started out as a ruby developer, and I personally think TDD is can be useful, but it's not the panacea that the TDD cargo cult proclaims it is.
I don't know about this one. I think that having to write print statements makes you do actual thinking about your debugging strategy and therefore makes you understand the flow of your code more. A debugger is certainly useful, but I was surprised the first time I had to go without one to find that I didn't miss it that much and possibly was even more efficient.
Is that not a problem of the codebase, language, and/or debugging system being used than a problem with printing/logging?
Print statement binary search is primitive, but it's survived as a tool because it's almost universally applicable.
IMO, all three: logging, printing and the debugger have their place. In theory, print statements could be 100% replaced by debugger macros or dtrace, but the tooling just is better (it is easier to keep your output the same across runs) for a class of "takes a couple of days to find" bugs.
Furthermore, and more controversially, if you debug with debuggers, you will be driven to use programming techniques that are friendly to your debugger. But when you debug with print statements, you are free to use whatever programming techniques are best for human comprehension.
Now before you raise your keyboard and rush to disagree, consider carefully that the position I just described is agreed with by well-known programmers such as Linus Torvalds and Larry Wall. There are equally well-known programmers who disagree.
The true merits of the case are hard to determine. But if you think that one side is trivially wrong, then you should view this as a learning opportunity. Because you're certainly mistaken.
See http://lkml.indiana.edu/hypermail/linux/kernel/0009.0/1148.h... and http://www.perlmonks.org/?node_id=48495 for more background on this topic.
By and large, the only time I can't reason through the problem on my own is because the code in question is not properly unit tested, and it is complex to isolate the problem itself.
The only time it's worth my time to bring out the debugger is when the issue is so opaque as to require that level of in-depth investigation. I've spent days tracking down esoteric heap smashers in gdb.
However, most of the time, I just watch my unit test assertions fail, and then fix the issue.
Regarding your criticism of #2, I think you're arguing orthogonally. The point to me seemed to be against TDD and the idea that code written "to" a test is inherently better. The point is to write and execute tests, not to fetishize how those tests are written or run.
And your point about #10 is just plain wrong, sorry. Arguments of the form "debuggers are easier than hacked-up logging" always presuppose that the "hacked-up logging" is hard to do. The fact that you feel more comfortable typing into gdb or whatever than you do adding a line of code and rebuilding tells me that you don't feel comfortable building and running your code. If that's the case, then you have already lost. Debug via printf works better because projects designed for debug via printf are inherently better. This applies to fancy tracing tools as well. They have their place, but if you can't whip out a printf then you need to fix that first.
Yeah, as originally written it basically reduces to "programmers with more experience are always better than those with less experience" and that's just not true. Side projects are a good sign that someone cares, and a good way to get experience faster than others and (potentially, unless you're just repeating stuff you already know in them) keep your experience diverse, but that's all.
I program in my spare time. I like it. But when interviewers want to pour over my "spare time" code before I get a job, it stops being fun. It becomes more work.
"Hi, I'm leaving. Oh, can I have a license for all the source code I've written?"
My side projects are for fun and playing around with new ideas, and don't really represent the style of code I'd be writing in a professional engagement. Here's an example from in the past: I wanted to crunch some baseball stat numbers using a Matlab library I'd found. So I hacked together some minimal parsing of publicly available game logs in Python, since I wasn't that interested in learning Matlab IO, then dumped them from Python to a format Matlab could read. Iterated that part until it worked for all the files I was interested on (but still in a rather ugly state) then hacked together some analysis in Matlab. DRY, or good design in general? Nah, it was a one-off thing.
My point was that sideproject code is better than no code at all. And it's not so much the quality of the code that's at issue, it's being able to talk intelligently about it. Hopefully you'd want to work with someone who can understand that something that is one-off is going to be lower quality than something you might write professionally, and having code to look at and examine that you wrote, that you're an expert on (because you wrote it), gives context to having discussions around how the code might be improved or why you made the decisions to made for a one-off.
Those people are instant no-hires. You aren't going to write code when I ask you to write it? That is your job!
(I would grant exceptions is very exceptional cases, like the candidate having physically lost his hands. Or being blind.)
And doing work for hire like this is considerd spec work in other industries
Are you talking about the company giving the guy a problem, and then taking his answer and putting it right in their codebase without hiring him?
Well... typically, my 'job' involves people paying me as well. If you want me to 'code when you ask for it', then you need to pay for that. Or... make it easier to judge how I do stuff (like look at my side work).
Hi, corporate code monkey here: that list looks entirely fine and not particularly controversial. Thanks.
The reason people think these things are "controversial" is that the sources of information these programmers are getting are often limited to their immediate environment, their university profs, and what they read online. That naturally excludes the bulk of competent programmers who don't blog or speak in conferences[1]. It's impossible to constantly remember to account for the biases in the media you consume, so people are naturally (and gradually) led to believe that the trendy ideas of yesterday and today are ubiquitous. They forget about the masses of programmers doing heads-down development on non-web, non-mobile platforms because the web and mobile guys are trendy and they all have blogs.
This is true, in that very few best practices are universally applicable and you should never stop thinking. The author is also totally right about people jumping on bandwagons and being cargo cult members.
So I'm not really disagreeing with him, but just adding that a lot of best practices actually aid your ability to reason through code. They can help to push repetitive things off to the automatic portions of your brain. They can help to make patterns in your code that are visible and familiar, so you can spend less time thinking about how to implement (or read) some simple thing and more time thinking about how the simple pieces fit together.
Which is not to say all "best practices" are great. But even the questionable ones usually have some interesting problem they are trying to solve that explains why they sprung into being. If a "best practice" is popular enough that it gets called a best practice, it's probably worth paying attention to and thinking about even if you ultimately decide not to use it.
If you face the exact same problem 10 times, and you think it through from the beginning every single time, you're going to get 10 different answers. You just can't remember all the little details every single time.
I agree, further, anything that can be automated should be. GTD and most similar systems stress getting everything possible out of your head and into the system, so you can concentrate on what is most important. Many "best practices" try to do the same, the trick, as you point out is to use the ones that are appropriate to your problem.
I disagree with one of the points supporting "Unit testing won’t help you write good code.", though, where he implies that writing the code reveals the edge cases. Surely the edge cases are something you should have carefully considered before starting to code? I've found that crystallising the edge cases as a test before writing the function can be really helpful.
TDD doesn't work well in every problem domain. Sometimes you have to accept that parts of your code can't reasonably be unit tested, and isolate the bits that are testable. But where it is a good fit, it's magic. My favorite book on the subject:
There are two kinds of edge cases: the essential ones that derive from your requirements and problem domain, and the accidental ones that result from implementation details like your choice of programming languages or which libraries you use or your software architecture.
You can try to identify the essential ones and write tests for them in advance, but for the accidental ones there’s only so much you can do with a black box approach to testing.
Being put on the spot is a different kind of stress that can take many people out of their game. Some managers may argue that they want to weed out people who cannot act under pressure but once a "team" is formed, the pressure of having to act quickly doesn't involve some of the socialization that is required in a job interview.
If you really want to know if someone knows how to code, have them write something for you. If you are afraid that they would cheat, look at their git hub account. Ask to see a portfolio if possible. If none of that is possible, make the hiring process take long enough that a level of rapport can be developed between the team and the candidate.
It's not necessarily looking for the best possible answer. In fact, I completely expect (as both interviewee and interviewer) that the candidate will write a first pass on paper, we will look at it, figure out it's big-O, and then go on to improve it to be better.
I think developers are putting themselves at a severe disadvantage and are being taken advantage of because of this whole 'hacker culture' or 'startup life' ideas.
We are making it the norm, and raising everyone's expectations of us which end up hurting us in the long run.
Stop for a second, and consider other professions and industries. Do you see lawyers or financial analysts play with side-projects in the weekend, and running all-nighters and hackathons? Or working on open-source-like-equivalents of their professions?
Sure they are different industries, but there are similar things they could do if they really wanted to, but they don't.
When we talk about 'hacking for fun' etc... we are sending a message to other people which changes their attitude to "hey i only pay you this much because you'd be doing similar stuff in your spare time anyways..."
People value your time based on things like this. Lawyers play this game very well, they pretend like they don't have a single extra second to spare, and hey they don't talk about law being fun either, and hence they can charge $200/hour fees and others will happily pay for it.
I think we need to be smarter and adjust our attitude to account for the economic goals and political games of the rest of the society.
As a senior engineer having done tons of side projects that I really enjoyed doing, when I approach a customer for a contract it is not rare that the customer tells me : "We could saw your code online / your involvement in that or that" so it is a good showroom for your skills.
Consider it as an investment, 1. because it is an opportunity to learn new stuff compared to your daily professional routine 2. because it is a way to demonstrate your skills.
Remember that you sell your expertise, not just your time.
BTW : yes, lawyers do pro bonos ! For exactly the same reason, for the fun of the case and their image.
Interviewer: "So, do you do pro-bono work?"
Interviewee: "Yeah, I've done some for some friends."
Interviewer: "Excellent, give us copies of all of it so we can determine how good of a lawyer you are."
That doesn't happen.
Ask yourself the following questions, keeping in mind that different people will answer differently and that's okay: Do you have a passionate desire to do what you do (whether your motivation be to build a better future, change the world, or create cool technology, etc.)? Or is programming really just a way to make money (i.e. "just a job") to afford the things you really enjoy? (Or some balance in between the two, usually.)
IMO for those who are truly passionate about their work, their work is NEVER "just a job". Thus while #17 is true for a great many people, it's not true for the few who tend to accomplish the most - at least judging empirically from historical results.
For these people, it's much more than "just a job". For every highly successful person who made a huge impact on the world, it's never "just a job." Just ask Elon Musk, or countless others, if they consider their career "just a job."
In short: find me a journalist or a writer or a musician or a sportsman who does NOT do some kind of side-project for fun or without being paid. They probably exist, but I bet there's not many of them - and I can suspect that they're viewed just as 9-17 programmers by the rest of their fields.
For musicians and writers (journalists are a type of writer), there's no actual distinction between what they do for work and what they do on the side, because anything useful they produce, they're going to publish anyway, in a way that doesn't substantially differ from the rest of their professional output. I'm sure they noodle around for fun, but a programmer "noodling around for fun" isn't going to have very much to show off on Github either.
I didn't know this. It makes sense, I suppose. But then again, why do you think those clauses are included in athletes contracts? Is it because they are unlikely to do any physical activity outside of their regular training or on the contrary, they would be active anyway and this is to prevent them from overworking themselves?
> [for musicians and writers] there's no actual distinction between what they do for work and what they do on the side
I disagree. Either one is paid to do something or is not. It's a job if they are compensated. It's not if they are not paid. This is how I understand this. Do you think that everything a writer ever writes is going to be paid for? Or that everything a writer writes he does in hopes of getting paid? I think that it is not the case.
I think this is exactly the same for programmers. We're writing code just as writers write prose. Sometimes we're compensated for what we wrote, sometimes we're not. Sometimes what was started as a quick letter to a friend becomes full fledged essay, and sometimes what was started as a 'hello world' in that new and fashionable language becomes useful product. More often this does not happen, of course, and that is how it should be.
But that's not the point. I wanted to say that being a programmer is more similar to being a writer or a musician than being a lawyer (maybe not - pro bono cases, as others suggest) or accountant.
This doesn't reflect how writers and musicians are actually paid, though. You might be in a band but have a side project or a solo album, but you still receive royalties or concert revenue for it, same as for your role in the ordinary band. Most writers make nearly all their money taking the risk that someone will publish their work and pay them for it. In either case, there's no real distinction and the financial returns are uncertain either way.
There are authors who have regular columns or something, but even in their case it's a little disingenuous to say that writing books is a side project. If you wanted to describe Thomas Friedman's profession, it would be something like "New York Times columnist and author". You wouldn't say he was a NYT columnist who happened to write best-selling books in his free time as some sort of hobby.
You are right, of course, but this is not what I was asking about. Let's leave 'nearly' (for clarity) out and let's say that 'all the money writers make comes from publishing their works', which is true. I'm asking if it's also true that 'all the writing writers do is supposed to/has to/they hope it will make them some money'?
[1] This requires more qualification. For instance, if one was a struggling writer who didn't make enough money from their writing but had a wealthy mother sending them money for their living expenses....
Certainly not many, because how anyone could know they actually wrote something? But I was speaking about published but not paid for works. There is more than one way to publish your writings and many of them do not involve financial compensation. I know, because quite a few years ago I was publishing short novels and articles in a (real-world, made-of-paper!) magazine about pen&paper RPGs. I didn't earn a penny (and the magazine went out of business quickly), but I was published.
I wasn't the only one who submitted texts to the editors of said magazine. Mine were of poor quality, but there were a few authors that I was not surprised to find in the bookstores some time later. They got a book contract (I don't know, I'm guessing) from real publisher probably with less hassle than other debutants, probably because of what they published for free earlier. You can argue that they became writers only after they were paid to write a book, but I don't see this that way. Also, many of them continue to contribute they writings (mainly reviews, essays) to on-line magazines (about RPGs; sadly, there is no one such a magazine still being published on paper in my country) for free.
How is this different from publishing side-project on github and getting hired based on that? I really can't see the difference.
Either way, thanks for interesting discussion, I enjoyed it, especially footnote about writing a letter to one's mom :)
I think the point is that when you're doing something you love, you want to keep doing it outside the constraints that exist when someone else is dictating the type of creative work you can do.
When you're doing something you love to the best of your ability, sometimes it's mentally exhausting and you need to do something totally different to recharge your batteries. Monomania isn't always the best way to go. I mean, it definitely works for a lot of people but it's not a reasonable expectation.
I know the current trend in startups is all about "show me your github", and I admit that it has some value as a filter, but I feel like I'm seeing people writing fairly uninteresting code snippets and blogs just to put it on their resume, in the same way that high schoolers join a bunch of student groups to beef up college applications. There are plenty of programming jobs that require writing complex code and having deep domain knowledge, and to discard those candidates because they can't show you their code and have other hobbies outside of work is just not smart.
As I said elsewhere, I really like programming and will often do it in my spare time because it's fun. But needing to maintain some public repo or an open-source project in order to get a job makes it no longer fun.
I completely agree, and I already have an above average amount of open source code available on Github. Some startups have found my projects and mentioned them in interviews, which was great, but I've never been directly asked for my code before an interview, and I like it that way. Writing code for the purpose of showing to potential employers would ruin the magic.
It's important to be open-minded and possess a large array of skills. Specialization is overrated, an invention from industrial era. Ideally, everybody should be a da Vinci.
Topic 18: His questions are not about writing code, they are about writing algorithms. The kind of code I write on a day-to-day basis does not require working with math equations of this type. I could eventually do it but I would probably have to research and test before I would be happy with it. Most definitely not something I could do on the spot during an interview, but I guess that means I can't write code.
I don't think I have much of a problem with the rest of them and agree with most of them.
What's the distinction between those? He isn't asking the candidates to invent algorithms, just to implement simple ones. The answer to the second question is "return Pi * radius * radius", isn't that just writing code?
As soon as 4 * 1/(2n+1) < 0.00001, then you can stop looping. The sequence is the algorithm.
while round(oldpi,5) != round(pi,5)
as your loop.
That the error must be less than the nth term does follow from 1) the fact that he says "more terms giving greater accuracy", which means the error must be monotonic, and 2) the fact that the sequence is alternating. Together, this means the two must be bouncing around the answer instead of inching toward it, and so the sum of the tail must be less than the current increment.
It won't work, however, for the general sequence (or even the general convergent sequence).
It's only the fact that it's alternating that makes it summable. The alternating series converges like 1/n^2.
This is the kind of thing that, if it's noted in an interview situation, marks a better than average candidate. It could also allow such a candidate to go on about problems with summing series, and really show off. (One secret to interviewing well being to make the given question into a question you know something about already.)
a) the numbers alternate between higher than pi and lower than pi
b) if you have a number between, say, 41 and 48 then the answer must be forty something and therefore start with a 4.
No more than 2 minutes insight really required! :)
I didn't say "invent" algorithms, I said write them. If I didn't happen to have that "simple" algorithm in my head already then it would not necessarily be trivial to implement it. Especially if it's been a while since you've worked with similar equations.
Now, if the goal is to see how the person would try to work it out allowing for questions to take the place of research then I could possibly see the benefit.
If you're given the outline for an algorithm, and asked to write code to implement it, is that writing algorithms or writing code?
The first one requires an ability, even if minor, beyond just coding while the second is all about coding. I also find it interesting that he says the second version was more difficult for his applicants than the first. Maybe instead of "algorithm" it's more about pattern recognition that leads to minor math skills to then coding.
Given that Pi can be estimated using the function [...], write a function that calculates Pi to an accuracy of 5 decimal places.
...my first inclination was:
public double answer() {
return 3.14159;
}
Normally I agree that algorithm-heavy CS problems are not representative of day-to-day software development, but this is pushing it. We're talking about a "return pi * r^2" here, in the latter example at least. The former example is a bit less realistic, but I could still see that type of logic being required occasionally.
And, yes, if you've had high school geometry, you should be able to answer question #2 without much trouble.
Although, after reading the second one again I can agree that it shouldn't be too difficult to complete since he essentially tells you what to do; you just have to write the actual code. Well, assuming you don't have to write code to estimate for Pi and can just have 3.14 in there.
(I will try it now.)
it can be answered in about 10 lines of C# is an unhelpful way of expressing how difficult a question is.
In the spirit of helping anyone who’s at that stage now, if you’re running on a slow machine, I suggest you try this sequence instead:
π² = 12( 1 - 1/2² + 1/3² - 1/4² + ... )
It converges much faster.
Typically, comments can just be merged into the code directly by extracting well named methods, and using better names for variables.
Good comments tend to not be redundant, they tend to tell you "why" information and be written at the level of intent rather than at the level of implementation. And thus they don't need to be continually updated when the implementation changes.
This. The exception being when things have to get messy for reasons of performance or other non-obvious constraints- at which point, the comments should document why it's messy, but may also provide some guidance around the messy code.
I have written comments as he described where they practically duplicate the code they are describing. But when I do that it's because I'm working with multidimensional arrays and I use comments to remind me what section of what array inside what array I'm currently working on. If I change the structure of the array and don't update the comments then that's my fault.
I was reacting more to the first sentence, where he said that "poor, incorrect, outdated, misleading comments" must be the most annoying aspect of comments. I believe he is right in this regard, but this where I feel he is blaming the tool for someone misusing it.
Actually, I think the problem is people tend to make comments which attempt to explain the function of the code at more than a high level. This is the mistake.
Your comments should explain the "why" of your code but seldom go into the "what", because the "what" will almost certainly change. And in fact, in many cases the "what" may not be entirely determinable from a single point in time with properly uncoupled code.
You can sit here and say "Oh yeah well its the developer's problem to update the comments don't blame the comments." but the observation that "what" comments get out of date is so universal that we should probably accept it as the norm.
Based on responses to my comment on this, I'm beginning to wonder if I need to approach explaining my thinking on this in a different way.
Do you think misleading comments should stay in place then? I'm confused why this matters.
To answer your question, a misleading comment should of course be removed or changed. Again, I fail to see how I was suggesting otherwise.
A tool, any tool must make it easy to use, hard to missues and most importantly protect you from damage when using it.
Based on that criteria, most comments make more harm than good.
For all intents and purposes this man is a glorified text editor.
He doesn't know the smallest bit of PHP (the stack with which he claims to work), CSS or HTMl - in which world is he a web developer?
If you only hire people who can write code during job interviews, you might get a great guy who was completely relax during the interview. Or you might get someone who's OK at writing code, and miss out on someone 100 times more productive only because they were nervous during the interview.
Nervousness is poison for thinking, fear is the mind killer, etc. I've always been most nervous at interviews for jobs I really, really wanted. Not because I needed a paycheck, but because I was passionate about the job.
Advice for job candidates: Drill coding under pressure.
So his comment is valid in that coders should code but his example of how to tell if someone can code I think is flawed.
#2 contradicts itself. It says that unit tests will make sure that code that already works doesn’t break but at the same time it won't help writing good code. Well as far as I'm concerned, code that breaks can't really qualify as good code. Writing tests first, or writing code to the tests is ridiculous. Not sure what writing code to the tests actually means, is that even correct English (I'm not a native English speaker)? The main benefit of writing tests first, is that tests do get written. It's too easy to say we'll write tests when we have time. If you discipline yourself to write tests first, by the time the code is written, the tests are written as well. Writing tests first also saves a lot of manual testing time (eg. clicking over and over in a UI), which is repetitive and stressful activity. Overall testing and TDD help a lot to achieve #11.
#19 is an amusing caricature, but misleading. Design Patterns are not limited to GoF patterns. They show up at different levels of abstractions and give developers useful vocabulary to communicate about stuff they do anyway. #19 mentions 2 patterns that are not very useful in our daily lives, but they are patterns like MVC, observer or iterator that we use all the time without even realizing they are patterns. The point of patterns (design, coding or architectural patterns) is not to memorize the GoF list but to learn to identify, label and share recurring solutions that we can reuse in various situations.
It’s idiomatic, and it usually has a negative connotation. An analogous example is criticising a school for “teaching to the exam”, usually implying that the school’s teaching is inappropriately prioritising getting the student a good grade in their exam, at the the expense of giving the student a good general education in the subject.
Here’s a contrived example of writing code to the tests, in the negative sense. Given this test:
def test_add():
assert(add(1, 1) == 2)
def add(a, b):
return 2In Kent Beck's "Test Driven Development by Example", he starts just like this, with an insufficient failing test. Then he writes a minimal function that passes it. Then he adds another test, then improves the function until it passes both. By the time he's done, he's got tests for all the edge cases he could think of.
I think it's a great way to make sure you cover all the edge cases, for a sufficiently complicated function. I don't have the patience to write all my code that way, though.
Yes, it is. The point is that even given many additional test cases of the same type, they will remain insufficient, unless of course you’re planning to test the entire input domain, which I imagine is going to take you a while.
Clearly at some stage you have to replace satisfying isolated cases with some form of generalised understanding. At that stage, you’re no longer coding to the tests.
This is not to say that unit tests can’t be useful. On the contrary, I find them a valuable tool for many programming jobs.
However, as I have observed before, the plural of “unit test” is not “proof”. I do find it frustrating when I see overconfidence instilled in too many developers just because they have a suite of unit tests available. Using TDD can’t magically guarantee that a program actually satisfies all of its requirements. Refactoring without thinking isn’t magically safe as long as the code still passes the test suite. Writing code to the test is not a substitute for understanding the problem you’re trying to solve and how your solution works.
No, the only thing you can say about the quality of code through tests is that if you change some code and it still passes the tests, then you didn't break it. The tests say absolutely nothing else, because their output is binary - pass or fail. They say nothing about the efficiency, readbility, complexity, or style of the tested code.
Tests can help take you from broken code to working code, and not a step further. To make it good code, you have to look at the code, not the tests.
But assuming well thought-out tests, that's a good indication that you haven't broken the code.
I prefer to have about 15-20 index cards with problems that have open ended solutions ("Build a RPG combat system using 4,6,8,10, 12 or 20 sided dice", "Create a system to store Books and allow people to search by author/title or genre")
If they insist that it must be solved at runtime, I would check the size of the computed term (1/(1+2x)) and repeat 'til it's less than 10E-6.
That's a lot of iterations.
iterate and alternately subtract and add 1/i, (then i=i+2) to get your multiplier.
Each iteration multiply 4 times the resulting multiplier. Break when the answer rounded to 5 decimal places == 3.14159
>Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.
I think we can assume he was just looking for something trivial.
Also, his next step down isn't really one jump down in difficulty; it's presented as "if you don't even know how to begin to approach that problem I need to make sure that you can code something trivial." That is to say, it's an arbitrary number of steps down that implies little about the initial question's intended difficulty.
My larger conclusion is that either the OP didn't intend to require this analysis or he's surprised that people in an interview+coding mindset are going to get stuck thinking there is a straightforward algorithm. Since he refers to the question as simple for any "seasoned developer" (read: has forgotten algebra ;), I presume he actually misstated the problem and really expected one of the simplifications people have come up with. Either way, I think it says more about the interviewer than the interviewees.
... although maybe my gripe only came about from knowing enough to immediately see that there had to be some kind of convergence bound, but not knowing/figuring exactly what it was.
p(n) = p(n-1) + 4*((-1)^(n-1))/(2n-1)
n = {1,2,3...} and p(0)=0
*Mental note: never start reply math on iPad ;)
You could be right though, in that the high number of developers who failed it freaked out at the site of pi and flubbed it without really thinking further. Although I think that says more about our horrible math education than anything else, i.e., math education is so bad that the mere site of something "mathy" elicits terror in the hearts of otherwise competent programmers.
A solution to this is looking at the distance from the current sum to the "boundary":
abs(round(sum, 5) - sum) > next_term
I guess that demonstrates why it's important to have a REPL or a compiler available for the interviewee. (My computer wasn't available at the time that I wrote the comment.) I just wrote up my solution and confirmed that its terminating condition isn't correct.
There's a mindboggling amount of people applying for programming jobs who can't even do that!
Of course, it's actually trickier than you might think on modern computers if you go out much further than 10 decimal places or so.
I have been a code producing developer for more than 40 years. I hate wasting time proving that I can do trivial problems. Sometimes I have spent half an afternoon writing one trivial problem after another. I would much rather spend the time looking at the company's problems and discussing solutions.
- "Programmers who don’t code in their spare time for fun [frequently won't be] as good as those that do.
- "Unit testing [may not] help you write good code [in many situations I have encountered]."
- "[Possibly the most useful] “best practice” you should be using all the time is “Use Your Brain” [though for some teams in some circumstances there may be more useful best practices]."
- "If you only know one language, no matter how well you know it, you’re [almost certainly] not a great programmer."
- "Readability is the most important aspect of your code, [depending on your company's goals and method of achieving those goals at this point in time]"
Of course, these are [mostly] opinions, and adding all sorts of disclaimers is [almost] never fun, but opinions stated as absolutes are [almost] always wrong.
I would go so far as to say that almost all the most important revelations I had programming-wise where when I learned a new language and suddenly gained a new way of looking at everything I know. And the nice thing about this is, you will keep these insights whether you stick with the actual language or not.
That said, there have been a few languages that have failed to do so. Almost invariably, I loathe working with them.
However, out of curiosity, how many people actually work on side-projects?
Because, after ten years, I have only worked with a couple of people who actively work on side-projects. And I know that some people treat programming as "only a job" and they're done at 5:00 PM, which is fine. But is it really uncommon that programmers work on side-projects?
[Shameless plug: I have a few small projects on GitHub (https://github.com/mattchoinski) and I also work on freelance projects for various clients.]
That's me, though. My overall point was that surely there are developers out there who feel the same about their job, even if it's not labeled "research."
Five years from now, my employer's standard technology stack might be obsolete. If I only gain skills at work, my skill set would be obsolete too. This would harm my future career prospects.
Could an employer pay me enough that I'd give up my side projects, sabotaging my future career prospects? Probably, but it would have to be a lot of money.
Of course, I also maintain a healthy work/life balance and have hobbies that let me get away from the computer and meet other people. This is also important.
I started using Ruby this summer and it was fun turning 10 lines of code into 1 or 2. But it was a big pain deciphering it weeks later =(
The idea is to remove as much accidental complexity as possible, to focus on the essential. Signal-to-Noise Ratio, basically.
Readability is the most important aspect of your code. Even more so than correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize, easy to change, easy to understand. And hopefully other developers can learn something from it too.
"XML is highly overrated"
Whoa. Steady on there, tiger. My brain can only handle so much controversy in one day.
"I'm not smart enough to understand this really complicated code, so I decided to write something smaller and simpler."
This is something a co-worker of mine said once.
Or maybe he's just humble that he's not smart enough.
I agree, the guy's comment is a bit of a paradox.
There is a reason why programming chops are not usually measured in lines of code.
In my opinion the "art" of programming is to keep things simple yet still solve the complex problems.
I'd say the guy was being humble for sure, as it seems extremely unlikely he would have the discipline to sit down and write something SIMPLE from scratch if he really was a bad programmer.
I've never seen it.
It's worth having getters and setters for variables that need to be publicly accessible, even if there's no logic in them, because it gives you the option to change how that data is stored in the future and not break all the code that uses it. You want to be able to change the implementation without breaking all your clients' code!
Fortunately projectlombok takes away most of this pain, and pretty much every modern language post-Java makes attributes/getters a non-issue.
I wonder if we can classify programmers depending on whether they are agreed with this or not. Something like a PQ (Programming Quotient)
I couldn't have said that better myself.
... by selling your company and pocketing enough to retire indefinitely.
What you do after that point you may still call "work" but you will be doing it for the fun or satisfaction of it, not necessarily a paycheck.
-- an amateur language designer