25 ms·

Controversial Programming Opinions (2012)

• lmilcin 6y ago
  > Programmers who don’t code in their spare time for fun will never become as good as those that do. I think this opinion is much misunderstood. It should read: people who are not interested in what they are doing are unlikely to ever become very good at it. People who are interested in a topic will have their brains work overtime at different times of day, will be picking up information even if they are not specifically looking for it, will be trying to understand stuff they are not specifically required to, and so on. As pointed by some people (like David Allen) our brains have something called Reticular Activation System which, if programmed, brings to our conscious attention when something interesting happens. And then we will also have easier time keeping focus. People who like coding will probably not see it as only work but also choose to do it in their own time and that usually results in private projects. I do electronics at home and this usually includes some kind of microcontroller and coding, just because I like it. But I don't have public repositories and I don't do open source projects because I do my own fun projects at work and get directly rewarded for it.
  • myspy 6y ago
    That's a good view on that opinion. I've kids and a wife that has a job, the spare time is taken up by them and the time I need to rest. I would if I had the time, but I'm interested in each and everything when working.
  • PragmaticPulp 6y ago
    This is also deeply misunderstood as an interview question. The idea that interviewers will reject candidates for not programming outside of work is a persistent meme now. The truth is that (good) interviewers don't care when/where/how you acquired your skills and knowledge. They just care that you have the knowledge and ability, and also that your learning is on a consistent upward trajectory. We ask if people do side projects not because side projects are mandatory, but because the goal of an interview is to surface any and every reason to believe the candidate is qualified. In practice, most engineers don't put side projects or hobby projects on their resume or even their GitHub profiles, and they won't spontaneously bring it up during the interview. Asking if they've worked on any fun hobby projects usually strikes up good conversation, loosens up the candidate, and maybe unearths some skills and interests that don't show up on the resume. If a candidate says they don't program outside of work, it's not a negative. It's neutral. We just move on.
    • lmilcin 6y ago
      As an interviewer I can only agree. I look for signs that the person is interested in what they are doing. Private projects with public repositories are a sign but nowadays I see people started showing up who force themselves to do these projects just to improve their interview prospects. I even had one person admit it when it was obvious they can't tell me anything about their own project. Obviously, this is a result of a very know effect where judging performance based on some measurements causes people to pervert this measurement. Other signs that people overlook and misunderstand is deep knowledge on any topic related to software development. If somebody could acquire good, deep understanding of at least one topic it shows they were likely at least at some point interested in it. People are sometimes put off that I seem to be asking large number of hard questions and then grilling to death, but that's what I am doing, looking for signs of being interested in something. I even have one question where I ask: What is the question you would like me to ask you? That's just another occasion to have a discussion on something where the candidate can demonstrate their deep knowledge.
      • PragmaticPulp 6y ago
        > but nowadays I see people started showing up who force themselves to do these projects just to improve their interview prospects. As an interviewer, it's fascinating to read forums like /r/cscareerquestions where people are working hard to game the interview system. Coding Bootcamps have also become bad at training students to pass interviews by practicing coding questions and putting cookie-cutter "side projects" in their GitHub profile. One of our local coding bootcamps had students post their class projects to GitHub as "side projects" to show to interviewers. The catch was that every graduate from the boot camp had the exact same "side projects" that followed the same formula. As an interviewer, it's amazing to see people arrive at interviews with an idea that we're just robots trying to check items off of a checklist. The internet pop-culture view of coding interviews is that they're just arbitrary gatekeeping that can be bypassed if you simply know which magic words to say to your robot interviewers. Tip for interviewers: Speak to your interviewers as if they were your future peers or managers.
        • 6y ago
  • warmwaffles 6y ago
    As I get older, I start realizing that I don't want to spend my free time coding all the time. I do like to take that time to build something with my hands, fix things around the home. I feel those are good critical thinking tasks and great experiences that can be applied to programming.
  • lastofthemojito 6y ago
    >If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. --Antoine de Saint-Exupéry I've noticed this in my software work. When I'm on a project that I'm personally excited by, I feel like I'm firing on all cylinders and am vastly more productive. Driven by COVID fear, I switched jobs over the summer to a company that would allow me to work from home. I'm not at all interested in the project I'm working on. And I feel like it shows...I don't retain things that coworkers have already explained, I don't feel a drive to learn more than necessary about the domain, etc. Maybe some of it is just COVID-brain, but my goodness being interested in your work makes a world of difference.
  • commandlinefan 6y ago
    #1: "Programmers who don’t code in their spare time for fun will never become as good as those that do." #17: "Software development is just a job."
    • lmilcin 6y ago
      I don't think there is any problem here. Not everybody has to be uber excited about everything they do. I surely can empathize with every person that wants to have a well paying job but just don't feel anything towards anything that is well paying. Just set your expectations realistically. If you are of slightly above average intelligence and you are not uber excited about programming (ie. typical developer), chances are you are never going to be rock star developer. Plan your career realistically taking that into account. Maybe work in area that doesn't require changing entire stack every 2 years? My friend decided consciously (we had a discussion) he is not ambitious but still wants to earn. He is now Cobol developer working with people that are on average twice his age. He has been and will be well paid for many years. He works 8h day, has time for his kids and other interests. He says he couldn't be happier.
    • moron4hire 6y ago
      Programming is not the same thing as software development. Software development requires programming, among many other things. Programming need not be towards the acct of software development. More specifically, I wouldn't call solving Project Euler problems "software development". It's a game, a puzzle, that requires programming. And I wouldn't call requirements analysis, UI design, testing, etc., "programming", But they are fundamental aspects of software development. It's possible to treat programming as a calling and software development an occupation.
  • deleted 6y ago
    [deleted]
• wagslane 6y ago
  Gonna add my own to this guy's (imperfect) list, "Engineering managers should be able to write code" https://qvault.io/2020/07/14/your-manager-cant-code-they-shouldnt-be-your-manager/ https://qvault.io/2020/07/14/your-manager-cant-code-they-sho...
  • whimsicalism 6y ago
    This is a controversial opinion on HN only because of how many managers & product people there are here. Of course engineering managers should be able to write code.
    • skohan 6y ago
      Yes I think it's a huge benefit to have managers who really understand software from personal experience. I have been in teams with non-technical management, and my experience is that so much time is wasted on irrelevant details. Often managers will ask the wrong questions, and do things the hard way because they're unaware of how the requirements could be modified a little bit to make the whole system work a lot better, and a lot easier.
    • darioush 6y ago
      The responses are telling of how controversial it is, as if people are trying to make excuses for why an EM should not be able to write code and how that's OK. It's not.
      • a1369209993 6y ago
        I suspect there's also great deal of "If a tree falls in the forest and no one hears it, does it make a sound?"-effect going on. Would you consider a secretary who coordinates a engineering team and handles communication between them and the rest of the company, but doesn't make any technical decisions to be a "engineering manager"?
  • jacobush 6y ago
    Sort of agree, it's enough if they could at some point. If they keep an ear to the ground about how things work and what's possible, that goes a long way.
• indy 6y ago
  Premature Generalization is worse than Premature Optimization
  • abainbridge 6y ago
    Related: Asking performance questions at the design stage is not a form of Premature Optimization.
  • gpderetta 6y ago
    As someone sometimes guilty of both, agree completely.
  • skohan 6y ago
    Yeah totally. Abstraction should be a response to code duplication, not a hedge against imagined future requirements.
    • dragonwriter 6y ago
      Abstraction should not be a response to imagined future requirements (though there is a fuzzy boundary between imagined and reasonably-foreseen near-future requirements: you don't want to spend effort solving problems from the hazy future, but you also don't want to be doing major rework in a month because you didn't take reasonable steps in anticipation of something clearly anticipated but not fully solidified), but code duplication isn't the only trigger. Problem decomposition often results in reusable abstraction as a natural consequence.
  • disambiguation 6y ago
    WET (write everything twice) > DRY (don't repeat yourself)
  • dragonwriter 6y ago
    > Premature Generalization is worse than Premature Optimization I don't think that's true, I just think premature generalization is more common among people who have internalized the maxim about premature optimization.
• mellosouls 6y ago
  (2012) Many of these still stand - but that's presumably because they aren't really controversial - as indicated by the popularity by vote. I think it's odd that the submitters of most of the opinions considered them controversial tbh.
• pelasaco 6y ago
  I don't see any controversy here.. all of the options are true, just not 100% of the time.
• ModernMech 6y ago
  > I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities. Because it’s the language used for the AP test. I hate it as well that students know it first.
  • m0ck 6y ago
    But it is still the case? From my experencie most CS universities starts with Python nowadays.
    • whimsicalism 6y ago
      My college CS education began with OCaml, I kid you not.
      • acheron 6y ago
        That actually sounds pretty good. When I went, our first classes used C++, but a couple years later they switched to beginning with Scheme. (IIRC it was PLT Scheme, which is now Racket.)
      • ska 6y ago
        lucky you :)
• Tade0 6y ago
  I see no controversy here. Anyway here's mine: readability is subjective and readable code must allow for exceptions in styling rules.
  • honkycat 6y ago
    See, I think code styling is a complete waste of time. And "readability" doesn't actually refer to how you format the code, it refers to how you design and structure your code. We have automated tools to format our code. They work great. They end arguments and take some work off your plate. Personally, I have better things to do than fiddle around where my curly-braces are placed.
    • whimsicalism 6y ago
      > See, I think code styling is a complete waste of time For manual code styling, I agree.
• banachtarski 6y ago
  My (slightly controversial) pet peeve is the abuse of the notion that "premature optimization is the root of all evil." Sure, let's not prematurely optimize, but let's also not use that as an excuse to make horrible decisions or unforced errors also.
  • tomxor 6y ago
    I agree but for a slightly different reason: I think the notion is also highly subjectively applicable... some types of problems really do need a lot of forethought to make efficient - waiting until later can cause significant problems when decisions are hard to pivot away from or undo. An easy example is DB design, the cost neglecting these considerations upfront can be massive and sometimes impossible to migrate away from.
    • jamil7 6y ago
      I agree with both of you. This quote is often used as a crutch on which to justify poor planning. Certain types of systems are very hard to "add" performance to as an afterthought and really need to be designed around it.
  • cellularmitosis 6y ago
    Indeed, when making a tech decision it is important to think about how expensive it will be to change that decision later on. Avoiding premature optimization isn't an excuse to carelessly paint yourself into a performance corner.
  • gpderetta 6y ago
    The full quote is much much more reasonable: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" Unfortunately everybody seems to forget about the last bit.
    • vonmoltke 6y ago
      I think the first bit, that is also always dropped, is also important: "We should forget about small efficiencies". Removed from that context, it has morphed into an excuse by some people to not pay attention to efficiency at all, even when the potential gains are large for a relatively small amount of work.
• honkycat 6y ago
  > Programmers who don’t code in their spare time for fun will never become as good as those that do. I live my life by the "4 good hours" rule, inspired by the book Deep Work by Cal Newport. If I can put in 4 good hours of deep work where I am iterating and learning on a skill, I consider the day a success. This rule is specific to improving at a new skill in flow state. This does not mean I blow off the rest of the day or refuse to answer emails after those 4 hours. I still exercise, answer emails, write documentation, cook dinner, etc. It just means I choose to be kind to myself after I've achieved those 4 good hours. After you work at a job for a while, things can tend to be come stale and you stop learning. I have a novel approach to this: I find a new job that will actually be challenging. This is actually harder than you think! In Deep Work, Cal estimates that you have 4 good hours of learning in you a day. Hell: You probably have less. The four hour rule refers to virtuoso violin players[0] who I am willing to admit probably have more talent and dedication than my stoner self. 0: https://www.johndcook.com/blog/2013/02/04/four-hours-of-concentration/ https://www.johndcook.com/blog/2013/02/04/four-hours-of-conc...
  • deleted 6y ago
    [deleted]
  • wolco2 6y ago
    There is the 4 hour a week movement.
    • flippinburgers 6y ago
      The problem with this is deep, intellectual work on the level of programming typically needs to be surrounded by communication loops. Minimum of six ours a day seems about as reasonable as it gets... It would have to be actual work though. Do we all honestly think the average developer would genuinely be able to set aside all the internet distractions and put their 6 hours in (2 hours communication + 4 hours development)?
  • PragmaticPulp 6y ago
    I've used time tracking apps for almost a decade now. I strongly agree that 4-5 hours deep work is a solid accomplishment in any office environment. Even on days where I spend 90% of my time in productive apps and don't have any meetings, it's still surprisingly difficult to pass 5 hours of productive time in an 8-hour work day. It's amazing how much time disappears to things like lunch, bathroom breaks, "quick" phone calls, and other breaks. That said, I think it's a mistake to believe that there is an upper limit on productive hours in a day. I'm part of a mentoring group where I see this idea stated as fact by a lot of juniors. The catch is that they've all read different sources that put the upper limit at anywhere from 4 hours to less than 2 hours per day. This leads to a self-fulfilling prophecy where they stop trying to work after they've reached their pre-determined target, whatever that is. When working alone or in isolation, I can often put in 10+ hours of measured, productive time in a day. The key for me is to do it in 2-hour chunks, with 1-hour breaks in between to recharge by playing with the kids, cooking and cleaning, exercising, and so on. I wouldn't recommend doing this consistently for an employer, but it's been a huge boost for hourly consulting and working on my own business.
• eyelidlessness 6y ago
  Almost none of these are controversial now (and the one about testing probably isn’t based on my own anecdata, but it should be), but I certainly remember many of them being controversial at the time they were posted. It’s fascinating as a sort of time capsule, and revealing that programming attitudes do still evolve. Of course we know this. We can observe it in the huge uptake of static typing and functional/immutable approaches in areas they were uncommon not so long ago. We can see it in the huge rifts over whether/how much to use JS on the web or how to build cross platform UI. But it’s interesting to me to look back and see how dramatically some attitudes have changed on topics that seem almost banal now.
• whack 6y ago
  > “What’s your most controversial programming opinion?” ... What follows are twenty of the highest voted answers By definition, the highest voted answers are also the least controversial. "Anti-establishment" and "populist" maybe. Unpopular? Certainly not. My controversial opinion is that most software tests should be integration tests that use randomized inputs. I doubt I'll get very many upvotes for that idea.
  • Sodaware 6y ago
    A bit like how /r/unpopularopinion on Reddit ends up being full of popular sentiments.
    • whimsicalism 6y ago
      > A bit like how /r/unpopularopinion on Reddit ends up being full of popular* sentiments. *racist
  • wolco2 6y ago
    That's more popular than you think. If you said php is a pretty good language and I enjoy working with it you may get a lot of closet php developers upvoting you. A real unpopular opinion is testing is not worth the effort.
  • pjc50 6y ago
    > most software tests should be integration tests that use randomized inputs. Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. I've seen this done with an automated spec translation tool that produced an unoptimised but correct H264 decoder and set of reference inputs to achieve coverage of the actual target decoder.
    • loup-vaillant 6y ago
      > Good for fuzzing, bad for determining whether the output is what you expected it to be, because finding out what the output should be is .. the reason you wrote the software. The solution for this is property based tests. Outputs almost never have maximum entropy. They have invariants, and they're related to the inputs in various ways. Trivial example: authenticated encryption. The input is some random text, some random key, and some random nonce. The result is a message. One property to check is the fact that the message can successfully be decrypted with the same key, and the resulting plaintext will be the same as the random text from the beginning. Another property is that any message that is not the message you computed will fail to decrypt (assuming you pretend not to know the key when as you corrupt the message). Testing (crudely) that you can detect forgeries (or at least accidental corruptions).
• teucris 6y ago
  > 6. Not all programmers are created equal [...] In actual fact, the performance of one developer can be 10x or even 100x that of another. The author points this out as controversial, possibly because it might make people feed bad. I think it’s just wrong. Measuring programmers by output means you’re ranking your team based on who’s doing the most in that context. That includes what opportunities they’ve been provided, their areas of expertise, the level of autonomy they’re given, etc. Getting people to reach their full potential is hard work. Sure, there are developers who require little to no effort to be high performers. Chances are it’s because of the opportunities they were given in the past to get there.
  • whimsicalism 6y ago
    Your claim is it is impossible for there to be a 10x difference in "full potential" and all apparent differences are because the "full potential" has not been unlocked?
    • teucris 6y ago
      There can definitely be a 10x difference in “full potential”. I think it’s super rare, and our ability to assess full potential is massively overshadowed by other factors.
      • whimsicalism 6y ago
        So explain again how > 6. Not all programmers are created equal [...] In actual fact, the performance of one developer can be 10x or even 100x that of another. is "wrong" given that > There can definitely be a 10x difference in “full potential”.
        • teucris 6y ago
          I like maccard’s response better than mine: > measuring two developers and saying one is 10x more productive than the other doesn't mean that the first is 10x better, just that they are 10x better at what you are measuring under the terms you are measuring. If you’re interpreting the author’s statement as an assessment of full potential, then you may be right. I didn’t read it that way, and honestly I don’t think that assessment can be easily made.
• Iv 6y ago
  What's controversial there?
  • Rochus 6y ago
    Good point.
• VBprogrammer 6y ago
  > Most comments in code are in fact a pernicious form of code duplication. Man, I used to work with a developer who, in basically all respects was a better developer than I am. But he was terrible for adding these type of pointless comments. When I'd point out in a review that his comment used the same 3 words as the code did in a different order he'd get all defensive.
  • wool_gather 6y ago
    I'd rather my colleagues repeat themselves in their documentation comments than provide none at all. So I think the habit of writing those comments is more important than making sure that every single one has no repetition. I'm working in a codebase now that has a frustrating lack of documentation of important details. A data field called "imageURL" that's a string -- is that a remote or local URL? Where did it come from/how much can I trust that it's well-formed? (And why isn't it already an actual `ParsedURL` type?) Another datatype has three fields "name", "username", and "id", all strings, with no explanation of their purpose or differences. This means that I either have to track down the teammate that wrote the code and ask them every single time I run into something like this. Or I have to execute the whole program and reverse engineer the answer. Both are colossal wastes of time compared to a few "useless" or "repetitive" comments.
    • disposekinetics 6y ago
      I had a teammate who would write something like the below and it drove me crazy. I assume this is closer to what the article meant. The below comment does not add anything to my understanding of what the program does. //Assign 5 to the val called a val a = 5;
      • wool_gather 6y ago
        Sure; that's a classic useless comment. Counterpoint would be a useful doc, where did the 5 come from? // Chosen by fair die roll. Completely random const kEschatonThreshhold = 5; val a = kEschatonThreshhold;
• mumblemumble 6y ago
  > Programmers who don’t code in their spare time for fun will never become as good as those that do. I would guess that the reality is more nuanced. Programmers who don't code in their spare time will probably find their knowledge becoming out of date. But that's because our profession doesn't really have a concept equivalent to continuing (Medical | Legal | etc) requirements, so we aren't really given an opportunity to sharpen our saw outside of our free time. But that's only if you're consciously doing it to learn new things. My guess is that spare time programming for the sake of spare time programming actually has a deleterious effect. Though I admit I base this on conjecture and over-inference into scanty evidence. There are some anecdotal observations that colleagues who spend their evenings and weekends grinding away on code have a tendency to also be the ones who have trouble concentrating or make burnt out fuzzy brain mistakes at work. And there's some empirical evidence from other domains such as language learners and musicians that, past a certain point, additional time spent practicing actually does more harm than good. Brains develop fatigue, too.
  • skohan 6y ago
    I actually think in general, if somebody is so into coding they can't help doing it in their spare time as a hobby, they probably will reach a higher level than people who aren't driven in the same way. Programming is very much a skill which is sensitive to practice, so I think more hours on the keyboard is a pretty good way to get better at programming. However I think programming "as a hobby" is a poor metric for judging who is going to be the best programmer, in terms of a hiring process, for two reasons: 1. It's already well-known that many companies will favor people who program outside of work during a hiring process, so many people will try to appear as if they are the kind of person who lives and breathes coding, and cultivating that image is much different than actually getting practice. 2. Raw programming skill is not always the best indicator of how good a contributor to a project someone will be. Sure you have to be competent at coding, but beyond a certain level, assuming the project is not particularly technically challenging like HPC or computer graphics or something, things like communication skills, being able to write good documentation, and being able to produce in a consistent and predictable way play as much a part in the team's success as being a wizard on the keyboard. And I say that as someone who does spend a lot of my free time coding.
• dilDDoS 6y ago
  > Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle. > Amazingly, more than half the candidates couldn’t write this function in any language I don't think this is true. Or, they were interviewing candidates fresh out of college who never really paid attention in any classes. Or, the problem was presented to the candidate in an overly complicated fashion (which is weirdly common in technical interviews) and the interviewee was confused, although that seems unlikely. I think it's easy to get wrapped up in this mindset of "oh we need super complex algorithm whiteboarding because candidates nowadays don't know how to code!" when you hear stories like this, and it's just not true -- at least in my experience of interviewing candidates. Maybe I've just been lucky.
  • wongarsu 6y ago
    There is a reason why fizzbuzz is a famous interview question. There are plenty of people who can't code (to any reasonable standard) but still apply to programming jobs. They might be fresh out of college, or they might come from a job where they were doing glorified IT or making Excel spreadsheets. "super complex algorithm whiteboarding" is obviously not the answer. You want something so simple no qualified person could fail even under stress, but hard enough that you know that the person is confident in writing if-statements. "Iterate a B-Tree in-order" filters too many people, "compute the area of a circle" is maybe a bit on the easy side.
    • whimsicalism 6y ago
      > "Iterate a B-Tree in-order" I'm not sure I could do this without a B-Tree class to look at, people say "b-tree" and really mean one of like 20 possible designs.
      • a1369209993 6y ago
        To be fair, if the interviewer is doing it properly, either they'll give you the data structure as part of question, or they'll let you pick whichever B-tree design is convenient.
    • 6y ago
• RangerScience 6y ago
  > Unit testing won’t help you write good code. Hard disagree. Unit tests themselves, yes, are really only great at regression testing. Writing code that is unit-testable helps you write excellent code.
  • skohan 6y ago
    I disagree. I think often times "making things testable" leads to code which is much harder to follow. For instance, dependency injection often leads to things depending on abstract interfaces rather than concrete implementations, and it becomes much harder to trace through code. I actually think integration tests are vastly more useful than unit tests, and in general unit tests should be employed: a) if you are testing business logic which is not obvious, b) as a method of debugging or c) when it makes it faster to iterate on a particular piece of code during development. I think excitement about unit-testing has become over-generalized to domains where it doesn't make sense. For instance, in a mobile application unit testing your networking layer does not add value 99% of the time, will be way less helpful than hands-on testing of the UX, and just adds busy work to modifying the code-base because you have to maintain the tests as well.
    • RangerScience 6y ago
      > depending on abstract interfaces rather than concrete implementations That's definitely a problem... in Java. I've had to deal with it before (in Java), and I think part of the problem is that people start using that abstraction pattern before there's actually multiple potential concrete implementations. In Ruby, I've applied something like this pattern, except all I'm doing is wrapping the service library to make my own DSL, and it's working tremendously well and allowing for excellent testing. And yes. Anything can be overapplied / mis-applied, and sure, unit testing might be more susceptible / abused in these ways. Essentially, I unit-test my functional code (libraries, etc) and I integration test my OO code (actual features, as the whole feature). It's not only a really easy way to test each kind of thing, but enforcing the functional library / OO features has led to (IMO) practically perfect code :D
      • 6y ago
• deleted 6y ago
  [deleted]
• qppo 6y ago
  > UML diagrams are highly overrated. Personally I think they're plain dumb. Not saying I can't hide my ego and move on, just that I think they're a massive waste of time on a leaky abstraction rooted in organizations that value talking about things more than doing them.
  • chadcmulligan 6y ago
    I disagree they're consultant gold :-)
  • thiht 6y ago
    UML class diagrams are overrated but they're not the only UML diagrams. UML sequence diagrams are pure gold. I have no idea how you can accomplish anything remotely complex without extensively talking about it (and writing it down!) first. It works fine for 2-months projects, but not for 2-years projects.
• progval 6y ago
  > I think too many jump onto the XML bandwagon before using their brains That one didn't age well; and it was only eight years ago! Unless you replace it with JSON, of course.
  • redisman 6y ago
    Ha. Even JSON outside of dynamic languages is actually not all that pleasant to work with. In JS though - brilliant.
• zinekeller 6y ago
  wagslane (or dang if you somehow stumble on this comment), please add (2012) on the title. Thank you.
  • wagslane 6y ago
    I got you
• altrunox 6y ago
  > If you only know one language, no matter how well you know it, you’re not a great programmer. Well, is this unpopular? If you only know a single language, and nothing else, I would think you are just good at reminding stuff you read, like guides and examples, and not that you really know what you are doing. Although I can understand when people don't know other paradigms.
• toolslive 6y ago
  > what’s your most controversial programming opinion? - Unit tests are a poor man's compiler (or a decent type system will decimate the number of unit tests). - Python is a toy. If you're developing a product there's always a better option.
  • jpcooper 6y ago
    How would you implement and test something something like C++'s unordered_set, a set with constant insert and lookup, using type-level constraints instead of unit tests? How would you represent this with types?
    • dragonwriter 6y ago
      > How would you implement and test something something like C++'s unordered_set, a set with constant insert and lookup, using type-level constraints instead of unit tests? How do you test asymptotic behavior with unit tests? It would seem that is the kind of thing which is analytically demonstrable from the input types knowledge of the same features of the underlying operations (and, thus, theoretically within reach of a type system, if you wanted to design a type system with that in mind), but only subject to loose approximation in anything like unit testing.
      • jpcooper 6y ago
        Testing asymptotic behaviour is quite simple. It can be done empirically. Yes, you might make a formal proof of asymptotic behaviour and the property that the iterator returns a set, given a certain approximate model of the system, of course. However, it doesn’t just become simple or practical given the existence of a suitable type system alone. Also I am not sure of the usefulness of tests of the asymptotic behaviour of an implementation of a data structure over tests over the applicable data and system. Is there a demand for this? What I mean is separate from the proof that a theoretical hash set had X complexity in its operations. That is clearly interesting. Unit testing might be for the poor man, but how much money will the man doing the formal proof have left at the end of it?
  • 6y ago
• tomxor 6y ago
  > Your job is to put yourself out of work [...] any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. This is a potentially dangerous one, my opinion is (when misinterpreted) this notion will make your product as disposable as your employees. While the examples given to achieve this are not themselves bad, in the wrong hands the notion of ensuring minimal effort is required to understand any code produced can be used to enforce mediocrity, to make difficult writing good code by reducing everything to the lowest common denominator out of fear of something being too difficult for everyone to understand... within reason, it's important to embrace and exploit qualities not shared by all employees - there is a risk in certain employees becoming difficult to replace, but it's better than the guarantee that nothing of value will be produced.
  • ChrisSD 6y ago
    Already this is essentially the ethos of large software companies like Google, et al. An employee is a cog that can be moved to any project or replaced/discarded as needed. [Exceptions are of course made for a handful of people they actually do value for one reason or another]. Software is treated the same if it's not a primary revenue source (even if it is profitable). Heck, if you want a controversial opinion then arguably "disposable engineers" is an openly stated goal of programming languages like Go. [I'm not sure I'd entirely agree with this opinion but I wouldn't entirely disagree either].
    • tomxor 6y ago
      You're not wrong... I think the irony in this is that it likely produces very large codebases in an attempt to maximize legibility - in such a way that devs new to the code will spend an equal amount of time traversing it and trying to find things as they would have trying to understand a more minimal but less boring codebase while also potentially improving their abilities. In other words it's lose lose for all.
• dTal 6y ago
  Pff, these are nothing. Buckle up! * 1-based indexing is superior to 0-based indexing. * If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding. * Relatedly, the 80 column "rule" is as stupid in code as it would be in prose. Use your aesthetic sense. * Vim and Emacs both have terrible user interfaces, and are an inferior experience to even a normal text editor let alone a decent IDE. Users have Stockholm Syndrome. * For beginners, BASIC is great and Python is terrible. * There are many languages with a 'mystique', like Lisp and APL. The correlation between 'mystique' and practical utility is inverse. * Source code should liberally use Unicode symbols. * Sigils to indicate variable type are actually pretty great, especially if enforced by the compiler. (See above regarding BASIC) Let the flames begin!
  • iab 6y ago
    I’m triggered
  • dpedu 6y ago
    Can you elaborate on the fixed-width fonts point?
    • gsoto 6y ago
      As long as source code resides in plaintext files, writing in columns (i.e. vertically aligning blocks of text) seems like an excessive endeavor with little gain. We are not typesetting; formatting resources should be kept to a minimum to make the code easy to handle in plaintext. Fortunately, code is restricted enough that we can do pretty well without those. You don't write spaces to align text in Word: it's a nightmare to maintain and the software provides better tools for that purpose. Why do we still write code as if we were using a typewriter? You may think you are improving readability by aligning columns of text, but then, the impossibility of standardizing such baroque formatting rules goes against that. Furthermore, you are preventing people from using a variable-width font, which is actually better for readability.
      • colejohnson66 6y ago
• wolco2 6y ago
  My favorite opinion is comments muckup the source code.
• jzer0cool 6y ago
  _> Unit testing won’t help you write good code_ How about: Unit testing can help to write "correct code". When I read through this list rewording in such a way could be less controversial and opinionated.
• msluyter 6y ago
  "The only reason to have Unit tests is to make sure that code that already works doesn’t break." I used to think this -- now I believe they have another almost as important purpose as a sort of "check your work" step. Not necessary for every "unit," but useful when a given class/method has high (irreducible) complexity.
  • thisiszilff 6y ago
    A lot of it boils down to another entry on that list > Use your brain IE, here is your confidence in our code (0...100%) and here are tools to increase that confidence (unit testing, integration testing, monitoring, etc.). At that point it is straightforward to say, "does this unit test increase my confidence?" and then go onwards. The thing is you need to learn to accurately gauge your confidence which can be difficult at times, especially when you are dealing with unknown unknowns, but if you iterate on it you get to a place where problems pop up in the areas you are least comfortable with and that is a good signal you're at least approximating it correctly.
• yazaddaruvala 6y ago
  I’ll add a controversial opinion, specific to programming an application: Premature Abstraction is the root of all evil. Don’t panic! The code will be a mess. Let is be a mess. Don’t abstract too early, or the eventual mess that regenerates will be even worse than without an abstraction. If a part of your application or assumptions in a piece of code haven’t changed for 12 months, then abstract that part of your application. However, only abstract the bare minimum.
• jameson 6y ago
  > If you only know one language, no matter how well you know it, you’re not a great programmer. Totally agree Here are my journey with programming languages with the learnings 1. Java - OOP, JVM, benefits of statically typed language 2. Python - Simplicity. Java's verbosity kills productivity. If used properly, dynamically-typed language boosts developer productivity 3. Java/TypeScript - Asynchronous programming with promises. It was mind blowing. 4. GoLang - Parallel programming with goroutines. Explicit errors as values reduces windows of having runtime errors.
• georgex7 6y ago
  > most comments in code are in fact a pernicious form of code duplication. I've found of the most frustrating things at my current job to be devs writing complex JS w/ 0 comments. Takes so long to understand wtf they're doing. I'd rather be on the other end of the spectrum. Ofc the middle path is best (minimal comments, when needed).
• skohan 6y ago
  > The only “best practice” you should be using all the time is “Use Your Brain”. > It’s OK to write garbage code once in a while. I feel like these two go together. I think something which is often forgotten in programming discourse is that the single most important thing which code can do is create real-world value. A lot of times we get caught up in coding the "right way" because we as programmers look at code all day, but the truth is nobody else is going to see the code once it's shipped, and it doesn't matter one bit to the user if it's beautifully designed code or a mountain of kludges as long as it performs the same. Sure good coding practices are important, but I actually think that an expedient solution now is often better than a perfect solution a week from now, and how well-factored particular piece of code is should be a function of how many times it should be touched rather than an absolute standard.
• kojiromike 6y ago
  > Unit testing won’t help you write good code. This is factual and irrelevant. Writing good software is more than just writing "good code". Unit tests help reproducibility. They help orient contributors, too, as failing tests give clues and passing tests give comfort. Plus, if you have automation like Dependabot updating your libs, you want a basic sense of whether the fully automatic updates are sane from looking at the test results.
• pelasaco 6y ago
  A good controversial one: Scrum turns great developers in average developers.
  • bujak 6y ago
    The corollary: it also turns "bad" developers into average developers.
    • balfirevic 6y ago
      That's not a corollary.
• dang 6y ago
  Discussed at the time: https://news.ycombinator.com/item?id=4448327 https://news.ycombinator.com/item?id=4448327
• commandlinefan 6y ago
  Well, it said controversial, and it didn't disappoint! I was surprised to see the one about getters and setters: "they make them private and provide getters and setters for all of them." I had begun to think I was the only person who felt this way (now I think he and I are the only ones). Getters and setters (and "datatypes" in general) miss the point of object oriented programming.
  • selfhoster11 6y ago
    Not only do getters and setters miss the point of OO programming, but (controversial opinion) they utterly kill it dead in Java. Every. single. Java. object. now has to have them. The average Java data class is a tiny stub at the top of the file that contains the class name and the data structure definition, followed by a parasitical mound of getters, setters and builders. This unsightly growth of boilerplate ends up being regenerated by the IDE tooling every time it changes anyway. I feel like I'm working with C, except that the code I'm editing has already been through the macroprocessor. Any needles of "smart" logic are drowned out in the haystack of dumb accessors. That same haystack, coupled with auto-regeneration, makes it very easy to clobber any "smart" accessors, so nobody dares to be clever. It's always logic on the outside of the class. There is a thing do'er that does something to the class, but the class has no idea how to do the thing with its own data by itself. This is the antithesis of the very ideas that OOP promotes. Whether they are a good idea is debatable, but the fundamental conflict cannot be ignored.
    • kondu 6y ago
      Thankfully, plugins like Lombok partially solve this issue - while we still have unnecessary accessors, atleast they don't pollute the source code and make it hard to read and navigate.
• city41 6y ago
  Software development being so opinion based is really irksome if you ask me. Code reviews often boil down to battles over opinions, people get caught up in bikeshedding a lot, and "famous" developers on Twitter can see their opinions practically become standards. I've also had managers consider things like TDD as absolute gospel. One of my favorite tools in the JS world is Prettier, mostly because it reduces the opinion surface. I want more tools and practices like that.
  • seph-reed 6y ago
    > Software development being so opinion based is really irksome > One of my favorite tools in the JS world is Prettier, I have no idea how these two statements can exist in the same comment. They're basically polar opposites to me. Prettier is one of the most obnoxiously, over-bearingly, self-indulgent opinionated pieces of code I've ever tried to work with. And they even say it themselves, with pride: opinionated.
    • city41 6y ago
      Because the opinion boils down to "use Prettier" or "don't use Prettier". If you have a team that can agree to that, then all the arguing over formatting completely disappears. You're trading trying to find some arduous compromise across the entire team with "whatever Prettier does". In my experience people are at first disappointed they don't get exactly the formatting they want, but once everyone gets used to it and formatting discussions completely stop, it's a nice relief.
      • edjrage 6y ago
        Please tell me how that isn't equivalent to "adhering to <famous developer on Twitter>'s gospel" vs. "not adhering to <famous developer on Twitter>'s gospel."
        • city41 6y ago
          Because the point isn't "Prettier's formatting is the best", it's "let's nip the argument about formatting in the bud so we can focus on much more important things". I couldn't care less who made Prettier, many tools in this space would likely accomplish this goal.
• MeinBlutIstBlau 6y ago
  #18 stands out to me. The question the guy is asking is a straight up math problem. I don't know about the average person here, but who often needs to calculate the area of a circle of determine factorials on a daily basis of coding? I can understand if you are in a field with the actual sciences or in gaming regarding physics. But for those of us who just manipulate data all day, why would you ask that question? We know how to program, not to do math. Sure if you gave us time to learn about how to do that kind of math we could figure it out, but on the spot asking "Do this math problem but in code" is like telling a construction laborer at an interview "What would you estimate is the proper weight of concrete laid upon a steel beam 200ft long?"
  • setpatchaddress 6y ago
    Those questions are perfectly reasonable sanity-check tests of basic programming skills (functions, loops, basic arithmetic). That person is not assuming you know how to calculate Pi -- they're telling you how to do it as part of the question.
    • MeinBlutIstBlau 6y ago
      How can someone be expected to know how to code something if they don't understand the basic concept related to the question? The only time I've ever seen an equation like that was in Trig or Discreet math. Both of which were college level courses. None of which were in basic loops or arithmetic I've learned in actual introductory classes. I cannot calculate the area of a circle without a Unit Circle. I'm sorry but that's just incredibly unfair to assume people just remember all the Trig they did like it was yesterday. Trig's easy, but who uses it on a daily basis? Machinists and Architects probably use it far more than we'll ever use it.
      • jevgeni 6y ago
        The question in the article doesn’t use trig. You only need a bit of an idea of how loops work and be able to recognize patterns.
• lninyo 6y ago
  Here are mine: * All children should be introduced to computation in BASIC. * Clojure is not an acceptable lisp. * Jerking off to complexity is not cool.
• flippinburgers 6y ago
  The sign of a junior developer: constantly injecting some new learned aspect into whatever they are focusing on the moment rendering your project a tapestry of broken shards of glass.
  • callinOutLiars 6y ago
    I think that is called a mosaic.
• forgotmypw17 6y ago
  If you're not at minimum duplicating your code, you're not writing resilient code. Every piece of logic should be written at least twice and verified against each other.
• musicale 6y ago
  > 1. Programmers who don’t code in their spare time for fun will never become as good as those that do. Not surprised that this would be controversial. > 17. Software development is just a job. A bit disappointed that #17 is controversial in principle, though it is certainly a hobby for some and a religion/obsession for others. Maybe what I'm looking for is "Software development can be just a job and that's OK - it doesn't have to be an all-consuming passion that devours all of your waking hours, even if your employer or boss thinks it should be. People with varied interests can be better developers than people who have few interests outside of software development or computing technology. Most software applications depend on expertise outside of software development, often knowledge in a specific application domain (such as science, mathematics, engineering, game design, business, or communication) as well as expertise in computer-human interaction or sociotechnical design." Hopefully that wouldn't be particularly controversial, but it probably would be. ;-p
  • trickstra 6y ago
    I think #17 says that software development can be just a job, don't forget to also have a life, don't sacrifice everything just for the job. But at the same time, if it's "just a job" and you find yourself annoyed going to work, doing it at the lowest acceptable quality level, never being proud of some elegant solution, then you'll probably never excel at it and it will be a nuisance for you and your teammates. So those are two different meanings of "just a job".
• dudul 6y ago
  2. Unit testing won’t help you write good code. This is idiotic. First of all, yes, as mentioned in the quote, tests will make sure that the code doesn't break if some rando changes it. But also, code that can be correctly unit tested is usually good, well-organized code. The simple act of writing code that can be properly unit tested is a significant step towards writing good code.
• softwaredoug 6y ago
  > “Googling it” is okay! I wrote a book called “Relevant Search” and created one of the most popular Elasticsearch plugins (Elasticsearch Learning to rank). I’ve worked in Solr, Lucene, and Elasticsearch for more than 8 years more or less constantly. I have, at any given time, dozens of google tabs open dedicated to Solr, Lucene, Elasticsearch. Sometimes on basic things to jog my mind. Knowing how to interpret information online, what exactly to search for, and having memory to be jogged by other context is just part of what it means to have a skill. Memorizing documentation is rarely a good use of brain cells IMO, even pre google when instead you used a book index/ToC to do the same thing.
• f2000 6y ago
  "Print statements are a valid way to debug code." In 30+ years of programming, vast majority of bugs I've fixed were diagnosed with a few strategically placed print statements. "I just print values. When I’m developing a program I do tremendous amount of printing. And by the time I take out, or comment out the prints it really is pretty solid. I rarely have to go back." — Ken Thompson in the book Coders at Work by Peter Seibel
  • toast0 6y ago
    I call this the 'printf' school of debugging. It works a lot of the time (but not always, not great for debugging locks on stdout, for example). If you only have time to learn one debugging technique, this is the one to learn.
  • Supermancho 6y ago
    Print statements can generally be thought of as unit tests that require 1 line of boostrapping code.
• luord 6y ago
  This was a fun game to play: Seven I fully agree with. Seven I agree with but I don't think they're controversial. Two I agree with but they're interesting in that I'm pretty sure that the ideals of them are not controversial, even if they're not as common in practice. One I agree with the title, but not the description. One might have been controversial back then, but it might as well be an axiom nowadays. Two I fully disagree with.
• young_unixer 6y ago
  My controversial opinions: - Good abstractions are hardware instructions on layers of steroids. Bad abstractions are tabula rasa models that don't acknowledge the nature of the operations that the hardware is doing. - "var id: type" syntax is both ugly and impractical. - "inconsequential syntax details" like my last opinion are actually important aspects of a programming language and not just bike-shedding. - If a programming language includes a package manager that points to a repository by default, then it's a not a serious programming language. - Drivers don't belong in the kernel. The kernel should just define an interface for you/manufacturers to write drivers for.
  • thiht 6y ago
    > - If a programming language includes a package manager that points to a repository by default, then it's a not a serious programming language. I'm not sure what you mean, having a default repository seems like a sane decision to me. Do you have a language in mind that doesn't do this?
    • Supermancho 6y ago
      You have to install package management tools and point to repos for most languages - Erlang, Java, PHP, Lua, etc. Very few languages include a package manager as part of the LANGUAGE.
• dmh2000 6y ago
  I can't believe #18, developers should be able to write code and the summary saying that he got some/many? candidates who couldn't. Its not that developers can't code, its that recruiters paid on commission will send any warm body to an interview.