1. 11

    Sure, there are plenty of solid “9 to 5” coders around. Some people have no passion for programming, yet are naturally gifted for it.

    However, one problem is recruiting. For every naturally gifted “pragmatist”, there’s a handful who have neither passion nor an aptitude for it. With enthusiasts it’s relatively infrequent you’d stumble on a total dummy. Perhaps that’s what is behind the GitHub participation interview metric (and the tendency to cheat that of course).

    1. 10

      I don’t think it’s fair to say someone who predominately writes code 9–5 isn’t “passionate”. There’s a difference between passion and singular devotion, and it’s entirely possible to be a good coder who takes pride in your craft while also, for the most part, pursuing other hobbies in your spare time.

      1. 15

        It seems like people are using the word “passion” in place of “competence”. You don’t have to be passionate to be a solid employee.

        1. 3

          Yes, when I wrote passionate I meant passionate. I can be good and very efficient at cleaning, that doesn’t make me passionate janitor if by life circumstance I end up doing that.

        2. 5

          I hope I will meet more 9–5 software developers who have a passion, who at 5pm can’t wait to see the end of the problem we’re debugging, who due to family/hobbies/whatever has to leave, but is yearning to get back the day after to together resolve the issue. These people and those for whom programming is their main hobby, they all inspire me and cause me to want to learn new things, figure things out, resolve issues and in general make things better. I hope I inspire others to do the same. :-)

          1. 7

            Well, hello there, I’m one. A passionate developer, who tries not to do work on my personal time. A few things to clarify though:

            • I believe you’re falsely equating the desire to end work at the same time daily with hating it. The former is just an issue of organizing one’s time that becomes more important the more responsibilities you take both at and off work. Coding without recess or sleep is usually a sign of a young person who can afford it physically. But it’s never efficient.

            • You don’t have to immediately shut off your work laptop at 17:00:00 to make it count. We’re not robots. When I have a few spare hours on a weekend I prefer not to log in to work and run tests I didn’t finish on Friday. I’m pretty sure Monday is going to be just right for it. But if there’s an occasional thing I think I can actually finish in half an hour extra work, I’m fine with it too. Just use your best judgment and learn not to slip into doing more and more work.

            • Dropping work every day at reasonable time doesn’t mean a programmer has no passion. It just means they have other passions, too.

            1. 1

              Hi, fellow passionate developer! :)

              I think I understand what you mean, but it is not about me thinking people hate their work. Perhaps it would be more accurate to say I might be “falsely equating the desire to end work at the same time daily with not caring too much about what you do”. What I’m looking for is the expressed desire or yearning to want to finish things, but having to leave for whatever reason. That is is enough for me, I’m not asking for people to sacrifice their family life.

              And I didn’t mean that one has to incessantly check one’s work mail or coding from home during the weekend, at the benefit of one’s employer (of course(!) one should get paid for the work, at all times).

              For me programming is not something I only do to get paid, I do it without getting paid too (own projects, or contributing to open source in my spare time). Hence I’m usually interested in what developers code or what tools they look into in their spare time when they are not limited to what the company, its development process, the project manager or the customers ask for.

              Sorry for not expressing myself more clearly. I hope my point comes across more clearly now, even though you might still not agree with me.

              PS. I don’t know so much about Chinese tea brewing, but I’m currently learning Chinese. :)

              1. 2

                Yes, it’s more clear now, thanks! Let me clarify myself as well:

                What I’m looking for is the expressed desire or yearning to want to finish things, but having to leave for whatever reason.

                The reason for leaving work at reasonable time is the acceptance of the fact that body and mind need rest in order to continue doing that work efficiently over a longer period. I don’t just cut myself out of it for the sake of not doing it. It wasn’t like that for me when I was in my twenties, but with age I learned that sweet spot of diminishing return when I know that pressing on for longer would produce too little for too much effort. So I learned to take my hands off keyboard and let my brain work on things in background, while I do my cooking/running/parenting/whatever.

                By the way, it doesn’t have to be exactly 8 hours. For myself I learned that I can’t really be in the flow for longer than 3-4 hours a day, with rare exceptions. And I’m lucky to work at a company that lets me manage my own time in this way.

          2. 1

            Sure you can redefine “passionate” to mean anyone remotely competent, but then we just end up needing another word for passionate, er, people who are interested in programming beyond their careers.

            1. 2

              I’ve beem thinking about this a bit today, so I’m going to try and distil those thoughts down here:

              1. Beyond a certain point in your career, a singular focus on code can become pretty limiting. The profession of software development encompasses so many different disciplines, and narrowly defining it as ‘writing code’ can lead you to neglect those.
              2. I write better code when I’m well rested, I’ve eaten well, and I’m in s good mood. One of the things I’ve had to learn to do is to cut myself off when it’s necessary; to not work ‘til 3am on that side project that I can’t stop thinking about, to go out and do stuff on my weekends and not feel like I’m wasting time I could be using on side projects. This one has been hard for me.
              3. Any job where you’re expected to tend to your professional development on your own time is a lousy job. I’m lucky to work at a company where we have time and money put aside each and e dry employee to spend on professional development, and I recognise this isn’t the case for a lot of working developers. But he point still stands.
              4. Often the concept of ‘passion’ and pride in one’s work is used by employers to justify things like unpaid overtime, unrealistic deadlines, and so on and so forth. I always feel guilty doing it, but sometimes the best thing to do is go home at 5, let your work wait, and not try to make unrealistic schedules work through Herculean will and passion.
              1. 4

                Beyond a certain point in your career, a singular focus on code can become pretty limiting.

                I find it interesting that you seem to see writing code as a means for career advancement. For me, the career advancement is the chore I have to manage in order to keep coding.

                1. 2

                  Can’t really object to any of your points, but I feel none of them has much bearing as to whether someone is passionate about something or not. My mention of passion wasn’t an attempt to guilt-trip, am perfectly OK with professionals who just do what they paid to do without consuming interest in the trade.

          1. 32

            In the Hacker News thread about the new Go package manager people were angry about go, since the npm package manager was obviously superior. I can see the quality of that now.

            There’s another Lobster thread right now about how distributions like Debian are obsolete. The idea being that people use stuff like npm now, instead of apt, because apt can’t keep up with modern software development.

            Kubernetes official installer is some curl | sudo bash thing instead of providing any kind of package.

            In the meantime I will keep using only FreeBSD/OpenBSD/RHEL packages and avoid all these nightmares. Sometimes the old ways are the right ways.

            1. 7

              “In the Hacker News thread about the new Go package manager people were angry about go, since the npm package manager was obviously superior. I can see the quality of that now.”

              I think this misses the point. The relevant claim was that npm has a good general approach to packaging, not that npm is perfectly written. You can be solving the right problem, but writing terribly buggy code, and you can write bulletproof code that solves the wrong problem.

              1. 5

                npm has a good general approach to packaging

                The thing is, their general approach isn’t good.

                They only relatively recently decided locking down versions is the Correct Thing to Do. They then screwed this up more than once.

                They only relatively recently decided that having a flattened module structure was a good idea (because presumably they never tested in production settings on Windows!).

                They decided that letting people do weird things with their package registry is the Correct Thing to Do.

                They took on VC funding without actually having a clear business plan (which is probably going to end in tears later, for the whole node community).

                On and on and on…

                1. 2

                  Go and the soon-to-be-official dep dependency managment tool manages dependencies just fine.

                  The Go language has several compilers available. Traditional Linux distro packages together with gcc-go is also an acceptable solution.

                  1. 4

                    It seems the soon-to-be-official dep tool is going to be replaced by another approach (currently named vgo).

                  2. 1

                    I believe there’s a high correlation between the quality of the software and the quality of the solution. Others might disagree, but that’s been pretty accurate in my experience. I can’t say why, but I suspect it has to do with the same level of care put into both the implementation and in understanding the problem in the first place. I cannot prove any of this, this is just my heuristic.

                    1. 8

                      You’re not even responding to their argument.

                      1. 2

                        There’s npm registry/ecosystem and then there’s the npm cli tool. The npm registry/ecosystem can be used with other clients than the npm cli client and when discussing npm in general people usually refer to the ecosystem rather than the specific implementation of the npm cli client.

                        I think npm is good but I’m also skeptical about the npm cli tool. One doesn’t exclude the other. Good thing there’s yarn.

                        1. 1

                          I think you’re probably right that there is a correlation. But it would have to be an extremely strong correlation to justify what you’re saying.

                          In addition, NPM isn’t the only package manager built on similar principles. Cargo takes heavy inspiration from NPM, and I haven’t heard about it having a history of show-stopping bugs. Perhaps I’ve missed the news.

                      2. 8

                        The thing to keep in mind is that all of these were (hopefully) done with best intentions. Pretty much all of these had a specific use case… there’s outrage, sure… but they all seem to have a reason for their trade offs.

                        • People are angry about a proposed go package manager because it throws out a ton of the work that’s been done by the community over the past year… even though it’s fairly well thought out and aims to solve a lot of problems. It’s no secret that package management in go is lacking at best.
                        • Distributions like Debian are outdated, at least for software dev, but their advantage is that they generally provide a rock solid base to build off of. I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.
                        • While I don’t trust curl | sh it is convenient… and it’s hard to argue that point. Providing packages should be better, but then you have to deal with bug reports where people didn’t install the package repositories correctly… and differences in builds between distros… and… and…

                        It’s easy to look at the entire ecosystem and say “everything is terrible” but when you sit back, we’re still at a pretty good place… there are plenty of good, solid options for development and we’re moving (however slowly) towards safer, more efficient build/dev environments.

                        But maybe I’m just telling myself all this so I don’t go crazy… jury’s still out on that.

                        1. 4

                          Distributions like Debian are outdated, at least for software dev,

                          That is the sentiment that seems to drive the programming language specific package managers. I think what is driving this is that software often has way too many unnecessary dependencies causing setup of the environment to build the software being hard or taking lots of time.

                          I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.

                          Often it is possible to install libraries at another location and redirect your software to use that though.

                          It’s easy to look at the entire ecosystem and say “everything is terrible” but when you sit back, we’re still at a pretty good place…

                          I’m not so sure. I forsee an environment where actually building software is a lost art. Where people directly edit interpreted files in place inside a virtual machine image/flatpak/whatever because they no longer know how to build the software and setup the environment it needs. And then some language specific package manager for distributing these images.

                          I’m growing more disillusioned the more I read Hacker News and lobste.rs… Help me be happy. :)

                          1. 1

                            So like squeak/smalltalk images then? Whats old is new again I suppose.

                            http://squeak.org

                            1. 1

                              I’m not so sure. I forsee an environment where actually building software is a lost art. Where people directly edit interpreted files in place inside a virtual machine image/flatpak/whatever because they no longer know how to build the software and setup the environment it needs. And then some language specific package manager for distributing these images.

                              You could say the same thing about Docker. I think package managers and tools like Docker are a net win for the community. They make it faster for experienced practitioners to setup environments and they make it easier for inexperienced ones as well. Sure, there is a lot you’ve gotta learn to use either responsibly. But I remember having to build redis every time I needed it because it wasn’t in ubuntu’s official package manager when I started using it. And while I certainly appreciate that experience, I love that I can just install it with apt now.

                            2. 2

                              I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.

                              Speaking of Python specifically, it’s not a big problem there because everyone is expected to work within virtual environments and nobody runs pip install with sudo. And when libraries require building something binary, people do rely on system-provided stable toolchains (compilers and -dev packages for C libraries). And it all kinda works :-)

                              1. 4

                                I think virtual environments are a best practice that unfortunately isn’t followed everywhere. You definitely shoudn’t run pip install with sudo but I know of a number of companies where part of their deployment is to build a VM image and sudo pip install the dependencies. However it’s the same thing with npm. In theory you should just run as a normal user and have everything installed to node_modules but this clearly isn’t the case, as shown by this issue.

                                1. 5

                                  nobody runs pip install with sudo

                                  I’m pretty sure there are quite a few devs doing just that.

                                  1. 2

                                    Sure, I didn’t count :-) The important point is they have a viable option not to.

                                  2. 2

                                    npm works locally by default, without even doing anything to make a virtual environment. Bundler, Cargo, Stack etc. are similar.

                                    People just do sudo because Reasons™ :(

                                2. 4

                                  It’s worth noting that many of the “curl | bash” installers actually add a package repository and then install the software package. They contain some glue code like automatic OS/distribution detection.

                                  1. 2

                                    I’d never known true pain in software development until I tried to make my own .debs and .rpms. Consider that some of these newer packaging systems might have been built because Linux packaging is an ongoing tirefire.

                                    1. 3

                                      with fpm https://github.com/jordansissel/fpm it’s not that hard. But yes, using the Debian or Redhat blessed was to package stuff and getting them into the official repos is def. painful.

                                      1. 1

                                        I used the gradle plugins with success in the past, but yeah, writing spec files by hand is something else. I am surprised nobody has invented a more user friendly DSL for that yet.

                                        1. 1

                                          A lot of difficulties when doing Debian packages come from policy. For your own packages (not targeted to be uploaded in Debian), it’s far easier to build packages if you don’t follow the rules. I like to pretend this is as easy as with fpm, but you get some bonus from it (building in a clean chroot, automatic dependencies, service management like the other packages). I describe this in more details here: https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging

                                        2. 2

                                          It sucks that you come away from this thinking that all of these alternatives don’t provide benefits.

                                          I know there’s a huge part of the community that just wants things to work. You don’t write npm for fun, you end up writing stuff like it because you can’t get current tools to work with your workflow.

                                          I totally agree that there’s a lot of messiness in this newer stuff that people in older structures handle well. So…. we can knowledge share and actually make tools on both ends of the spectrum better! Nothing about Kubernetes requires a curl’d installer, after all.

                                        1. 2

                                          Does his gopher link still work? The gopher client has been removed from most browsers.

                                          1. 3

                                            This random gopher proxy seems to render his page just fine.

                                            Apparently there was an add-on/plugin called Overbite that used to make Firefox/Chrome natively support the gopher protocol, but it seems like last round of add-on API changes broke it permanently.