11 ms·

Just let me code

186 points by TheCraiggers 12y ago

danso 12y ago
> For a long time, I've attributed this frustration to the complexity of today's software. The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. Where is the joy in that? I dunno...The significant overhead is mostly because we attempt to latch on and leverage existing platforms and useful technologies...and so to complain about it would be like Isaac Newton, instead of appreciating standing on the shoulders of giants, complained how in the good ol days, pi was just 22/7. Awhile ago, I tried to make a simple Chrome plugin that would let me filter Reddit IAMA's by dynamically hiding all threads that didn't involve the IAMA-host...simple enough to conceive it as a jQuery snippet, but I had to spend an hour learning how Chrome plugins worked, all of its conventions...and then about three hours digging up why inline click handlers were unaffected by my jQuery code (Chrome recently considered manipulating existing onclick events to be a security risk). A total pain in the ass, considering that the code to solve the problem was "easy"...but I understand the tradeoff here...I didn't have to code my own web browser, and when playing with other people's browser environment, security can't be ignored. If I wanted to avoid these hours of learning about the Chrome ecosystem, there's nothing stopping me coming up with my own bespoke way (such as querying the Reddit API programmatically and re-constructing the iAMA as I wish on my own webpage), but that has its own tradeoffs. I do think, though, that for novice programmers...the overhead must seem immense. It drives me a little crazy to see bootcamps attempt to teach non-programmers Rails. Yes, Rails is in demand, but for a long time, these novice coders think that running "rails new" is a prerequisite for every web project.
- rane 12y ago
  You could probably have written a userscript which is considerably easier, although not as easy to distribute.
- knowaveragejoe 12y ago
  > I do think, though, that for novice programmers...the overhead must seem immense. Agreed. This is why I recommend sites like Codecademy, Khan academy, etc, to just get started and see if coding is for you. Purists will argue that they're teaching you their way to code, but it at least gets your foot in the door in two important ways: getting over the hurdle of environment, and getting the syntax of the language. In my personal experience, teaching someone(very interested but with zero experience) to code without some sort of boilerplate already in place was very frustrating indeed. Only after several hours and lengthy explanations of what things are and why they are used later could the actual coding begin. After completing enough of one of those options to grasp the syntax and language constructs, you can slowly introduce things like terminals, version management, environments, scripts, etc. As they wrap their head around each piece such that it's not in their way, they can get back to the coding that they're trying to focus on.
hyperliner 12y ago
"Coding" as a primitive activity has become subservient to the goals of coding. What are the goals of coding? - Make money - Solve a problem In any non trivial pursuit along those two vectors, complexity typically creeps in because more people are involved. Since more people are involved, this becomes a human organization. A human organization is not concerned with only the primitive activity to be done, but also what are the right approaches, methods, measurement, priorities, politics, scaling, learning, etc. Therefore, one cannot just be doing the primitive activity and ignore all of these higher level goals. I am going to use an analogy: let's say coding is brick layering + painting + wall building + carpet + etc. and we are going to build a building. The worker says he just "wants to do work" but if we let her do that the building would be a disaster, unless you are just building a dog house. In which case the risks are low and a single person can do the work. At the beginning (startup), one can just "do coding" because the problem is ill defined and an organization has not been established to manage the higher level work. I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert.
- treerock 12y ago
  To use your example the workers can generally just turn up and work. The bricklayer doesn't have to be concerned with the carpets. The joiner doesn't have to worry about zoning restriction. I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.
  - sanderjd 12y ago
    I think this actually does happen to some extent. The larger an organization and longer it's been around, the more likely it is that some people on the team spend some or all of their time working on tooling for the rest of the team. When done right, this means that most of the team members just need to follow some well documented or automated process to get fully up and running, and never need to really think about all the moving parts.
  - 12y ago
danielweber 12y ago
Don't forget to change the toolchain every few years. "Sorry, we need someone with 3 years of Docker experience."
erikb 12y ago
This is exactly the reason why I avoid any "Java/Android/iPhone" job out there. I code software in Python on Ubuntu machines. Simple bike rides. The build tools are either non existent (Python) or are old friends (make/automake/cMake), the IDE is a bash and a vim, like a handle bar and pedals. Git, much like vim, is a mastery in itself but when the disciple reaches a certain level most of the annoying things make sense and work as desired because how they are. The Zen of Unix and the Tao of Testing are my companions. Nothing disturbs my chi. What I am trying to say so eloquently (or not) is that maybe the problem is not the modern development world but the developer. The idea that you need just another tool to solve a problem, that is what is flawed. Skill and balance and a set of powerful, basic tools, that is what solves the problem.
- lnanek2 12y ago
  Honestly, I've never seen anyone use anything other than XCode for iOS. Android, it's true there is Eclipse and Android Studio, but Eclipse support for modern build system features like binary packaged Android libraries is lacking, so people are being forced off it. So there isn't much choice for either any more. Android does have a lot of devices and versions to test on, but iOS tends to have almost everyone on the latest version and just few screen sizes, so it isn't an issue. So I can see avoiding Android, but not iOS for this reason.
  - jimmaswell 12y ago
    >Android does have a lot of devices and versions to test on Ironic how the choice of Java and sandboxing was meant to make this not necessary
    - thezoid 12y ago
      You are comparing apples and oranges. If you are running the same application on equivalent hardware at the same API level then you should be fine. Android has issues with hardware as well as the various API versions. The closest parallel in Java would be comparing a Pentium 4 running Java 1.3 vs some 12 core server running Java 1.7 or something.
kayoone 12y ago
In web programming it's especially complex imo. Take a new programmer that can program basic stuff. He wants to learn server side programming and suddenly needs to setup a bunch of servers(vm, vagrant or docker) , needs to learn git, needs to learn how a framework works because you don't want to teach spaghetti code. Then there's html5, Css and probably some template language and a lot of js in modern apps. Add less, sass, coffeescript testing, rest, a js framework and websockets and you have a totally overwhelming setup which is the standard for most apps today.
- jimmaswell 12y ago
  >He wants to learn server side programming and suddenly needs to setup a bunch of servers(vm, vagrant or docker) I didn't use any of those things while learning web/server programming. Just a laptop with Debian and Apache installed.
- dllthomas 12y ago
  You don't generally need to "setup a bunch of servers" when you're first learning web programming, and a "new programmer that can program basic stuff" can hopefully already use git - counting that as part of "web programming" as distinct from other programming is hugely disingenuous (git was created for programming that was not web programming). What's left isn't trivial, to be sure, but I don't know that it's harder than getting set up to do development on a microcontroller. More languages are involved, but languages are rarely the hard part.
conductr 12y ago
This is why I recommend all "learn to code" people to start with PHP
- virmundi 12y ago
  My issue with your advice is that I then have to trouble myself with learning Apache or some similar server stack. Last time I worked with Apache, over 10 years ago, it was annoying, to say the least. What we need is a simple solution. I recommend bottle or flask. Documentation is available. Easy to start. A good community to work with for learners. Will it scale? To Hell with that. No beginner should have to worry about that. They need to worry about first principles. Then work their way up.
  - conductr 12y ago
    virtualenv and deployment are why I don't recommend python for step 0 beginners Most people I've talked to at this level, they are so far away from being "technical" that HTML/CSS is already a huge (unavoidable) hurdle and the simplest thing I can imagine is PHP + FTP. If they get on an FTP client that mimics the GUI of a folder system, people get it real quick - they are copying this local file to another folder on the server. To me, the quicker you can get them to deploy something the better. because the first steps are to understand how information is sent to your app, understand that it's your apps job to make sense of that information and return a response. I also tell them to get a cheap standard shared host, so most of the apache is transparent to them anyways. When they get to the point of needing to customize apache, that's an incremental step from where they have already gotten
rainer89 12y ago
In theory that tools that the article rage about are designed to help us to solve problems , make us more productive and help us to make more money.
krschultz 12y ago
I hear him on the added overhead of build tools, testing tools, ticket trackers, code review, and the like. They have their place, but I wouldn't describe them as 'fun'. But for me, Git is integral to writing code. I couldn't image writing code without version control. Git makes experimenting risk free and encourages me to try things and move quickly. There is no risk of breaking anything because you can always go back to the previous working state. There are other tools that are surely just as good or better than Git, but I'm pretty convinced it is a 40 year technology, much like Unix or Vim. It's worth the time to get really, really good at Git. I see it no differently than learning how to use a decent text editor.
- billmalarky 12y ago
  "Git makes experimenting risk free and encourages me to try things and move quickly. There is no risk of breaking anything because you can always go back to the previous working state." Having built a large project without version control I can safely say git is the best thing to ever happen to my coding productivity and enjoyment. Without version control my anxiety goes through the roof any time I have to work on a large codebase.
clarry 12y ago
Is there something to back up the claim that you must use git and a popular bug tracker to get any community involvement?
- falcolas 12y ago
  git, mercurial, svn, cvs... different names for the same tools and challenges.
  - clarry 12y ago
    > But if a potential contributor wants to fork your code, you'd better understand pull requests, branching and merging, and a whole series of other operations that might or might not have counterparts in the SCMs you've used. I don't think these tools are all the same, at least as traditionally used. And you don't have to (ab)use all their features. Also, you don't have to use these tools at all. But the original author more or less claims that you have to use git to get any community involvement.
    - falcolas 12y ago
      I read it as github being the most popular example of that type of tool. If not github, then SourceForge, or code.google.com, or launchpad, or... the list goes on. And whatever community you ascribe to, you'll have to learn how to operate within it to get community contributions.
      - clarry 12y ago
        I guess such communities exist, but it looks weird to me. It shouldn't be like that. I mean, your project's community should consist of people who use or are interested in using your code. Whether it be hosted on github, launchpad, your own yourproject.com or another server capable of hosting the project. Hosting it is technical details; people should come to the project for what it is, not for where it is hosted at. Therefore the community shouldn't be "github community" or "sourceforge community" or whatever. Or did you mean communities such as "git users", "cvs users" and so on? I think that's still the wrong way to think of it. It sounds like a religious cult formed around specific tools. They're just tools. I shouldn't need to ascribe to "vim community" hosted on "vimhub" even if I wrote my software using vim (I don't).
ixtli 12y ago
I am wholly in favor of writing tools that do one thing well and make it a priority to get out of your way. That said claims like "Git is that it's a whole subworld on[sic] to itself" seem absurd in this context. Perhaps this is the authors problem in general: the trick to productivity is being able to quickly reach functional understanding of a tool/library you've decided to use. Enough to 1) evaluate the tool/library itself and 2) use it in a way that's at least somewhat conformant to how the authors intended. Obviously doing these two things requires good authors and good client programmers. However, if being a large body of work kept developers away from things you certainly wouldn't have a zillion apps on the iOS app store.
clueless123 12y ago
I just want to paint said Michelangelo.. but now I spend all my time mixing paint and building scaffolding and such.. SCM,Frameworks and such are part of the price we pay to be able to build larger and larger projects.
mynegation 12y ago
Oh the irony of an analogy... The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places (once you are set up, that is). Version control, build systems, compilated makefiles, testing frameworks, profiler sessions, deployment scripts - all that takes time to set up, but pays handsomely on all projects of non-trivial size and length. The right thing to do is not to get rid of this "overhead" but make this setup as easy as possible.
- deleted 12y ago
  [deleted]
- TheCraiggers 12y ago
  >The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places That's a rather insightful thought that I didn't think of while reading the article. Keeping the analogy going, I'll point out that there is a large difference between bike riding and jetting around the world. As far as traveling goes, one could think of bikes being analogous with enjoying the journey, and flying being analogous with enjoying the destination. Despite the fables and memes, enjoying one over over the other isn't inherently wrong in my opinion, but different people will prefer one over the other. Some people will prefer the simple act of creating something with your own hands using (relatively) simple tools. Like a craftsman building a nice table. Others will prefer huge projects, the skyscrapers and the like. When I first read the article, I was only thinking of the one side, but your post has helped me see that creativity takes many forms.
  - nmrm 12y ago
    I have another apt application of this already-stretched analogy, but I think it works well w.r.t. the pain of doing large projects without the right tools: A bicycle ride to the next town is enjoyable. Paddle boating across the Atlantic gets old fast.
- sebcat 12y ago
  I really like the go(1) approach of testing and profiling, and together with Docker and git it really makes for a easy-to-setup environment. Library-first (as opposed to framework-first), write your foo.go and foo_test.go, run go test -bench ., iterate, deploy to devenv, run integration tests, push to live. Works great, no hassle.
andyjohnson0 12y ago
Tim Bray recently wrote [1] about feeling "stuck and discouraged" by complex tooling and frameworks. Excerpt: "In fact, for every hour I’ve put into actually fiddling with Java code, I’ve invested another fighting git submodule subcommands, and now I’m staring at what feels like a thousand-meter-high Gradle rock-face." "I should count myself fortunate that I’m not building a browser-based app; I’d have to budget an even higher proportion of the time staying on top of this week’s funkiest new JS libraries and scrambling to have Wave effects before everyone has them and they’re boring." He also links to Ed Finkler’s "The Developer's Dystopian Future" [2] which was on HN a while ago and addresses the same topic. [1] https://www.tbray.org/ongoing/When/201x/2014/07/17/Discouraged-Developer https://www.tbray.org/ongoing/When/201x/2014/07/17/Discourag... [2] https://the-pastry-box-project.net/ed-finkler/2014-july-6 https://the-pastry-box-project.net/ed-finkler/2014-july-6
- _pmf_ 12y ago
  From the instigator of XML, which is generally respected as beacon of simplicity, straight-forwardness and common sense[1]. [1] http://en.wikipedia.org/wiki/Billion_laughs http://en.wikipedia.org/wiki/Billion_laughs
pjc50 12y ago
There's a lot to be said for reducing the "time to first results" for people getting started on a platform, whether that's absolute beginners or people retraining to the new trendy thing.
dsugarman 12y ago
I agree with the concept that no one wants to deal with the overhead that comes with working on a distributed product or team, but tools like git have largely reduced the complexity and allowed programmers to get back to coding. without build scripts, you will spend a lot more time outside of coding.
badman_ting 12y ago
I worked at a place that had people whose responsibility was the workflow, precisely so that developers could focus more on writing code. Then people started doing their own projects (good) so they wouldn't have to use .NET anymore (good) but they never took the time to get the workflow right (bad) and each new project worked slightly differently or was built on a completely new and different platform (bad) so now everyone has a more complicated workflow than they used to, and they're all different. No automated testing, no CI, no reasonable way of deploying code and certainly no rollback, who has time for such frippery? I left.
michaelochurch 12y ago
I remember, during a short-lived consulting gig back in 2012, trying to convince a company to use Scala. They panicked about the lack of IDE support and refactoring tools. "IDE support is immature." Response: well, true, but you don't need an IDE. Java makes IDEs mandatory because it's a crappy, verbose language. Scala doesn't. Clojure especially doesn't. Haskell doesn't (although convincing that company to move off the JVM would have been impossible). "Where are the refactoring tools?" Response: when you have good static typing, the compiler is far better at enforcing refactoring safety than any tools on the market. (Java itself combines the worst of static and dynamic typing.) People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes. Then there is the myth of the "full stack developer". It's a good idea in theory, but no one knows what it means. It's just management "at the end of the day, it's all about leveraging our core synergies" bullshit. What's really going on is that execs and professional managers can't evaluate the work in most specialties, so they've decided to pretend that specialties don't exist. All types of programming get thrown together into "it's all code; just make the thingy work" and what that means is that programmers get stuck cleaning up any kind of technical mess they have the bad fortune of having thrown to them. The result is that a good number of programmers (those who aren't savvy enough to play the game and be selective in what work they do) end up learning a bunch of crappy, parochial, non-transferrable "how we do things here" details but (a) never get a coherent career or develop the ability to protect a specialty, and (b) are constantly learning "new" but ill-thought-out and incoherent things. For what it's worth, I used to think that this was a "new" problem, or a symptom of the industry getting worse. I'm not so sure that it's very new. Maintenance programming, 20 years ago, was the same slog that it is today. If anything, the situation is getting better. I agree that Git is not user friendly at all, but the damn thing works, and it's far better than other VC tools (e.g. Perforce).
- pnathan 12y ago
  Great point. Many devs won't touch a tech stack that doesn't have tons of tooling and lots of ceremony possible. (To those used to such things, you will find something tremendously freeing if you drop down to using no language specific tools but the compiler/interpreter).
mzarate06 12y ago
I agree with the overall point: tool complexity can be a major downer and impose residual drag throughout a project's life cycle. I too "just want to code". However, I don't agree with some of the author's examples. Git has proven to be rather simple, minus the initial 1 week learning curve (of casual use, give or take). I use it in solo private projects and in teams. Branching and merging, in particular, are part of why I love it so much; much better than the CVS and SVN days. And isn't using SCM considered a best practice? I think so, but I'd be interested in hearing any counters. I also find build tools essential. Even for web apps, simple ant scripts that automate remote tasks have proven invaluable, especially wrt deployments.
- mmphosis 12y ago
  And now you have two problems. What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" where someone outside or most likely inside the CDN (our competitor) will take it. There are a lot of things deemed best practice. Best practice for who? And, to what end? Here is a best practice: release developer tools for your platform that are the only way to build software for your platform. Locks in developers to your platform. Makes it difficult to switch or port to other platforms. Enables ways to thwart competitors, by slowing down their development cycle or even stopping it at the approval point. Enables ways to steal ideas and even code. Why do you think each major platform has their very own programming language and plethora of platform specific APIs? A floor of moving snakes is not much fun. One vendor even called their platform ASP. Simple build tools. The ant script is simple, but installing ant is not. And, we don't really want ant and the dependencies it requires. But, whatever works for you.
  - mzarate06 12y ago
    > What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" ... Then move your SCM server wherever "internally" is? SCM does not require "the cloud". Regarding ant not being simple to install ... would you mind elaborating? I've installed ant a handful of times, either via "sudo apt-get install ant" or as a plugin to my editor; both ways were simple IMO. And I agree with simplicity, particularly with dependencies. I mentioned ant off the cuff, though I also use shell scripts when I can. They handle most remote tasks I can do in ant, but w/a smaller foot print.
codingdave 12y ago
One key is to stick with a toolset long enough to work out all the kinks and become effective with it. Constantly churning your tools leads to frustration. Everyone also has their own preferences. The author was stating how much harder a web app is vs. a mobile app, but I find exactly the opposite to be true. Just pick your tools, learn them, get good at them, and then code for a long time before changing. Don't get caught in the trap of always needing to try the newest thing. Focus on your core purpose of delivering a product, and you'll find that even a non-ideal toolkit still gets the job done, and you can stick with it for quite a while.
- gfodor 12y ago
  Exactly. You always have a choice, most of these things can be punted on. For example, I continued to use svn for many years before transitioning to git, despite everyone around me saying how great it was. It was a tradeoff, I am happy to know and love git now but at the time I wasn't ready to add that to my plate of complexity. In the end, I was able to focus on shipping sooner instead of learning a new SCM. The trick is learning how to recognize when something is no longer a fad but a true shift, and git eventually became obviously that, so I took the time to learn it. I think the ThoughtWorks Radar is a good resource for this type of thing: http://www.thoughtworks.com/radar/#/ http://www.thoughtworks.com/radar/#/ The assumption in this article is that you always have to be using the latest whiz bang tools and platforms, but that's up to you -- the "fashion" aspect of software development is the problem, not the tools per se.
Roboprog 12y ago
My own pet peeve is Ant/Maven. Sooooo complicated to do so little more than Make. (Running on Windows instead of *nix isn't worth much to me, personally)
colanderman 12y ago
This is why I have side projects. My SCM is Darcs (ridiculously simple); I don't use an IDE, only a text editor; I build with Make or by throwing all the source files at the compiler; I test sparsely by hand; and I deploy only to my own client and server so I don't need a configure script or any JavaScript feature-testing madness. It's wholly unsuitable for anything professional, and it's wholly a joy.
trevor-e 12y ago
Most of this article is hyperbole. I work on a large Android application, and while there's some overhead the majority of my time is spent coding. Look at any other engineering discipline and the overhead they have to deal with for their projects. Overhead is intrinsic to any large engineering project. As programmers we are actually spoiled with the fast feedback loop available to us. Learning all the tools is part of the trade. Yes, it can be a pain to do everything, but these tools wouldn't exist if they didn't produce some sort of net gain.
billyhoffman 12y ago
"Premature optimization is the root of all evil... and tools are just another optimization." -Me, ripping off Knuth The vast majority of tools exists to optimize and scale your time. Very few tools beyond a compiler/linker are required for software development. Depending on the size of your project, taking the time to learn a tool or set it up may not be worth it. Setting up build scripts and CI systems may be totally stupid for one project, and essential for another. The trick is to know when it makes sense to optimize your workflow and manual tasks with tools.
ionrock 12y ago
At some point I think it is important as a programmer to take pride not only in the result of the code, but the code itself. Efficiently managing a project can and should be rewarding as well. Developer usability is a very important feature. As a programmer, we write and iterate on code until it is ready to be published to the upstream repository. Our tooling has come about to help take our rough and ugly hacks and massage them into well written code we can be proud to push. Also, banging out code is overrated. I've found that when I take time to think, my actual coding becomes closer to what you see in the movies. I can find my flow and quickly materialize my ideas, and most importantly, solve the problems that arise. When I try to just "code" it ends up being poorly designed and written. The point here is that when you do have the desire to "just code" take a step back and consider taking pride in the code you publish. The tools and systems in place are there to make you a better code publisher. The goal is to write well written code that others (including yourself) can maintain. Rather than being frustrated you have to deal with the intricacies of rebasing or 3-way merges, take a moment to understand these skills will help you publish better code.
- stinos 12y ago
  When I try to just "code" it ends up being poorly designed and written. this. Not really important for small and/or personal projects, but for anything beyond that simply spitting out code ends up in a bad design violating SOLID and everything else out there, more often than not. After I figured that out, "code" now actually for me means something along the lines of "think about how components should cooperate with a minimum dependency, [enter rest of SOLID and everything else out there here], then start spitting out the tiniest functional pieces needed to implement it from the bottom up". Might not work for everyone, but it has done wonders for me. Especially the more my knowledge/experience about the first part grows (i.e. thinking about design upfront), the better the second part (i.e. spit out actual code gets), and the more proud I am of it. Heck, code from past two weeks is actaully a new personal record for me. So beautiful and well-cratfed :]. Then again, I thought the same thing about a piece I wrote 6 months ago. And the same goes for the way I use all other tools in the build process actually.
- mattgreenrocks 12y ago
  The desire to "move fast and break things" keeps you firmly in the 1 year of experience repeated 5 times camp. They teach you to overvalue tools like frameworks and languages and undervalue your use of them. It reinforces a consumer notion of technology, whereby you passively play in conceptual sandboxes constructed by The Great Framework Authors. "Just use Rails!" you hear, ignoring the small voice in your head wondering if all of the beauty of computation can really be foisted into ill-chosen paradigms. The cognitive killswitch that is mass acceptance and cultural success overrides that voice, though, so it's all good. Then, when you inevitably get things into a mess, you consult the inevitable cottage industry of people who give you tricks to ward off the pain temporarily.
TeMPOraL 12y ago
I feel his pain. This trend starts to seriously scare me. So the other day I wanted to learn a JavaScript client-side MVC framework. For various reasons I picked Ember. Suddenly, I had to spend a day playing with... Node.js (hey, I was trying to do client-side work!). Hundreds of megabytes of tools and libraries; package managers, web servers, a half of an operating system, just to generate a Hello World example in the way Ember documentation says is right (I also skipped the Ruby on Rails part). An example that, generated, had literally tens of thousands files and directories. Now the question is, why on Earth do I need to install Node to play with client-side JS (that is supposed to work, like, in browser)? Why do I need to subscribe to a particular TDD-ish development regime? Why every project nowdays uses a random build tool written in/for completely unrelated programming language? I've recently seen C++ code for AVR being compiled and loaded by Scala build toolchain. I get that some of this may be useful in large multi-team projects. But for small code written by one or few programmers? I feel it's only a distraction. I smell cargo cult.
- collyw 12y ago
  Is it my imagination, or is this problem fairly JavaScript centric?
  - TeMPOraL 12y ago
    I don't think so. More like webdev-centric (everything nowdays uses random build and test tools that are not necessarily in Node - sometimes it's Python, the other day it's Ruby...), but then again while working in an Erlang shop some time ago I went through two different build tools (one of them was made for Ruby libraries, btw.). And don't get me started about Java.
    - mattgreenrocks 12y ago
      The webdev stack is so, so bad. It gets an enormous pass because programmers love programmer culture, and it's open. (Exactly like the lackluster Linux of the nineties being immune to criticism due to openness). You know what a great workflow is? Vim, C, and a Makefile. C offers a far more conceptually complete model that isn't forced client/server. The C compiler does basic checks on my code (revelatory, for sure), and the Makefile, as horrible as the syntax is, can be added later. If I'm teaching someone, they can open something like gedit, type some code in, and run gcc manually. Boom! A program to run!
levifig 12y ago
This might sound crazy, but I'm on the "other side" of this conversation: I'm incredibly passionate about the management side and "shit umbrella" functions of software development. I'm driven by helping make sure developers can do what they love and do best: code! :)
webmaven 12y ago
"Having fun, yet? We haven't even begun to code." Whoah, waitaminnit... At least some of those decisions can be deferred if you like. You've decided on Git or some other SCM you're more familiar with. OK, fine. Nothing stops you from using it locally and deferring your decision on where to put a shared repo until later. Same goes for ticket tracking, continuous integration, testing, and so on. And if you want, just skip them for now. Heck, if you really want to, you can even defer using an SCM. Nothing is stopping you from starting your project, building it privately, sideloading it into your personal device, and deferring almost everything else infrastructure-wise until later. Yes, if you are building for iOS, you need XCode. If you are building for Android, you probably want Eclipse. But that's about it in terms of required infrastructure. You almost certainly can 'just start coding' if you want to. In fact, given that it is smart to 'build one to throw away' anyway, starting out by avoiding the initial overhead isn't necessarily a bad idea.
gavanwoolery 12y ago
I do agree with the author a bit. It's not that all these toolchains are useless (they aren't) -- its just that they should be a far more invisible part of the process than they are. The pinnacle of this frustration was when I used to contract native iOS apps. The sheer amount of crap you have to crawl through to do something nontrivial is ridiculous - and I'm not even talking about getting into the app store. This is one reason I started to fall in love with javascript. I've been a longtime critic of the language, but I'll be damned if there is not an easier way to build, test, debug, and distribute code. Growing up, I learned from MS QBASIC - which was an incredibly easy portal into coding. It is a shame no such things are commonly available today.
- recursive 12y ago
  I started with QBasic also. Things like that still exist. See http://plnkr.co/ http://plnkr.co/ and others.
ErikRogneby 12y ago
Programming small memory footprint embedded systems still requires you to figure out how to pedal that bike the best you can.
egypturnash 12y ago
I think this is something that happens to any field. I trained as a 2D animator. When you start, it's great - there's just you and the drawings. You can make anything happen. But once you start to want to make something bigger than a couple of seconds, things get complicated; you have to plan a script, wrangle multiple scenes, start involving other people to break up the process in various ways - inbetweeners fill in frames between what the lead animator draws, cleanup artists neaten things up, colorists, background painters, 3D people for stuff that's a pain to do by hand... plus all the non-drawing support people. Watch the credits at the end of any animated feature. All of them. Every single one of those people put in a lot of hours to make that film happen; not all of them did work that shows up directly on the screen. But all of those people had an important part to play, and all of them had to have ways to communicate with each other. I burnt out on that because I didn't want to be a cog in a machine designed to tell stories to the largest possible market. Now I draw comics. And guess what? I've got to deal with learning how to put together a website, put together a book for print, promote my work, go to conventions and sell stuff, etc. It is just barely doable by one person; I've been spending three years doing a ~400p graphic novel by myself, and I've got about a half a year left before it's done. I have template InDesign documents, scripts to help fill those templates, friends willing to try to make sense of the in-progress work and tell me when things don't make sense, sprawling directory structures full of source files and web/print res files, sketchbooks full of planning, etc etc etc. It helps that I was already able to wrangle a website; I'm slowly turning my custom templates into something anyone who wants to present a comic online the same way I am can use. If I wanted to start telling a lot more stories a lot more quickly, I could start parallelizing: separate the job into writer/artist/colors/lettering, find an existing publisher willing to handle packaging/printing/distributing to comic stores, bookstores, and e-stores, as well as shop it around to Hollywood. I can knock out a nice standalone drawing in a few hours. I still do that every now and then when I need a break. But my aspirations are higher; I want to create a world for the reader to inhabit for a few hours. And that takes a lot more work. Every kind of complex project has its own kind of scaffolding that users of the final project will never see.
- raverbashing 12y ago
  That's a very nice example, thanks for sharing. Good process makes your work of being "a cog in the machine" much more easier (and abstracts the rest for you - and of course, your work will be abstracted away for other people)
FrankenPC 12y ago
Personally, the scaffold doesn't scare me. It's the fact that the scaffold moves with regularity.
FrankenPC 12y ago
Personally, the scaffold doesn't scare me. It's the fact that the scaffold moves with regularity.
wpietri 12y ago
The false comparison here bothers me. Sure, back when I learned to code I could just type some stuff in on the machine in my basement, type "RUN", and have magic happen. Yes, it was stuck in my basement, and it couldn't do much, and it wasn't connected to anything. And yes, it could do exactly one thing at a time. But it was still pretty magic. This guy wants the same experience when building for a computer a million times more powerful, one that fits in his pocket. And he'd like to access a global network of satellites that shout timestamps so that he can, in real time, calculate his precise position and then record it. While that computer continues to do all the things that he expects of it, like letting him take phone calls and receive email from anybody in the world while playing whatever song or movie he'd care to watch. Oh, and he'd like other people to be able to run his app, suggest improvements, view his source code, and offer fixes. I think it's great to want things to be easy; that sort of irritation is what drives us to make better tools. But a big problem here isn't that the tools are overly complex, it's that he wants a lot more than he did 30 years ago.
- ternaryoperator 12y ago
  Not sure I see how that's a false comparison. What does the additional capabilities of the platform have to do with the incremental amount of yak shaving? You're implying that the notoriously tedious Android builds are the result of the phone's underlying prowess? Maybe they're difficult because the tools used are balky.
  - wpietri 12y ago
    It's not the complexity of the platform as such, it's the complexity of the desired result. If he wanted to write a little C and burn it to a simple, tiny, single-purpose computer that he just used himself, the toolchain for that is still pretty straightforward. I'm sure the tools could be improved. But I think he should acknowledge that a simple developer experience 30 years ago was simple because his desires were relatively simple. (And because the tools had been polished enough that simple desires were simply accomplished.) What he's asking for is more complicated. Should the tools mainly hide that complexity? Sure. But that doesn't come for free.
epaladin 12y ago
No one is stopping anyone from writing applications by themselves and distributing them by standard installation packages on a website, like what has been common since about 1995. No one is forcing you to set up an open-source project with distributed source control. No one is making you deploy on the app stores. Those are complex systems, and so it's no surprise that setting them up is non-trivial. Learning about Git is almost certain to be simpler than re-writing something Git-like every time you want a DVCS. Submitting to an app store is probably easier than trying to get your program listed in every software directory that exists for a given platform outside of that app store. Of course these things can be simplified a bit, and likely will be, but I think the current state of things is expected as part of the transition to new models of collaborative work and software distribution.
mcguire 12y ago
> ...now so overwhelms the developer experience... Now? This is not a new sentiment. In fact, it's older than I am. That may qualify it as a cliché.
hectip 12y ago
This isn't the internet we were given. This is the internet that we lost. Everything is locked down. Web pages with more style than content. ISP's capping upload speed, preventing me from running a small home server.
CmonDev 12y ago
This is my problem with Unity3d. Just like XNA, they picked a very good language (C#) but then they reduced it to scripting. So basically creating an app became just integrating pre-made chunks of third-party scripts/binaries + some assets from the store sprinkled on top. Furthermore it forces their architectural vision of what components and entities are about and there is no customization available on lower levels.

186 points by TheCraiggers 12y ago

danso 12y ago

> For a long time, I've attributed this frustration to the complexity of today's software. The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. Where is the joy in that? I dunno...The significant overhead is mostly because we attempt to latch on and leverage existing platforms and useful technologies...and so to complain about it would be like Isaac Newton, instead of appreciating standing on the shoulders of giants, complained how in the good ol days, pi was just 22/7. Awhile ago, I tried to make a simple Chrome plugin that would let me filter Reddit IAMA's by dynamically hiding all threads that didn't involve the IAMA-host...simple enough to conceive it as a jQuery snippet, but I had to spend an hour learning how Chrome plugins worked, all of its conventions...and then about three hours digging up why inline click handlers were unaffected by my jQuery code (Chrome recently considered manipulating existing onclick events to be a security risk). A total pain in the ass, considering that the code to solve the problem was "easy"...but I understand the tradeoff here...I didn't have to code my own web browser, and when playing with other people's browser environment, security can't be ignored. If I wanted to avoid these hours of learning about the Chrome ecosystem, there's nothing stopping me coming up with my own bespoke way (such as querying the Reddit API programmatically and re-constructing the iAMA as I wish on my own webpage), but that has its own tradeoffs. I do think, though, that for novice programmers...the overhead must seem immense. It drives me a little crazy to see bootcamps attempt to teach non-programmers Rails. Yes, Rails is in demand, but for a long time, these novice coders think that running "rails new" is a prerequisite for every web project.

rane 12y ago
You could probably have written a userscript which is considerably easier, although not as easy to distribute.
knowaveragejoe 12y ago
> I do think, though, that for novice programmers...the overhead must seem immense. Agreed. This is why I recommend sites like Codecademy, Khan academy, etc, to just get started and see if coding is for you. Purists will argue that they're teaching you their way to code, but it at least gets your foot in the door in two important ways: getting over the hurdle of environment, and getting the syntax of the language. In my personal experience, teaching someone(very interested but with zero experience) to code without some sort of boilerplate already in place was very frustrating indeed. Only after several hours and lengthy explanations of what things are and why they are used later could the actual coding begin. After completing enough of one of those options to grasp the syntax and language constructs, you can slowly introduce things like terminals, version management, environments, scripts, etc. As they wrap their head around each piece such that it's not in their way, they can get back to the coding that they're trying to focus on.

hyperliner 12y ago

"Coding" as a primitive activity has become subservient to the goals of coding. What are the goals of coding? - Make money - Solve a problem In any non trivial pursuit along those two vectors, complexity typically creeps in because more people are involved. Since more people are involved, this becomes a human organization. A human organization is not concerned with only the primitive activity to be done, but also what are the right approaches, methods, measurement, priorities, politics, scaling, learning, etc. Therefore, one cannot just be doing the primitive activity and ignore all of these higher level goals. I am going to use an analogy: let's say coding is brick layering + painting + wall building + carpet + etc. and we are going to build a building. The worker says he just "wants to do work" but if we let her do that the building would be a disaster, unless you are just building a dog house. In which case the risks are low and a single person can do the work. At the beginning (startup), one can just "do coding" because the problem is ill defined and an organization has not been established to manage the higher level work. I wonder to what extent this mentality of "just want to code" is related to the (stereotypical) aversion of the developer as anti-social and introvert.

treerock 12y ago
To use your example the workers can generally just turn up and work. The bricklayer doesn't have to be concerned with the carpets. The joiner doesn't have to worry about zoning restriction. I'm curious if software development (in large organisations) will ever reach that level of specialization, where a coder will be able to 'just code', because others workers will be employed to handle everything else.
- sanderjd 12y ago
  I think this actually does happen to some extent. The larger an organization and longer it's been around, the more likely it is that some people on the team spend some or all of their time working on tooling for the rest of the team. When done right, this means that most of the team members just need to follow some well documented or automated process to get fully up and running, and never need to really think about all the moving parts.
- 12y ago

danielweber 12y ago

Don't forget to change the toolchain every few years. "Sorry, we need someone with 3 years of Docker experience."

erikb 12y ago

This is exactly the reason why I avoid any "Java/Android/iPhone" job out there. I code software in Python on Ubuntu machines. Simple bike rides. The build tools are either non existent (Python) or are old friends (make/automake/cMake), the IDE is a bash and a vim, like a handle bar and pedals. Git, much like vim, is a mastery in itself but when the disciple reaches a certain level most of the annoying things make sense and work as desired because how they are. The Zen of Unix and the Tao of Testing are my companions. Nothing disturbs my chi. What I am trying to say so eloquently (or not) is that maybe the problem is not the modern development world but the developer. The idea that you need just another tool to solve a problem, that is what is flawed. Skill and balance and a set of powerful, basic tools, that is what solves the problem.

lnanek2 12y ago
Honestly, I've never seen anyone use anything other than XCode for iOS. Android, it's true there is Eclipse and Android Studio, but Eclipse support for modern build system features like binary packaged Android libraries is lacking, so people are being forced off it. So there isn't much choice for either any more. Android does have a lot of devices and versions to test on, but iOS tends to have almost everyone on the latest version and just few screen sizes, so it isn't an issue. So I can see avoiding Android, but not iOS for this reason.
- jimmaswell 12y ago
  >Android does have a lot of devices and versions to test on Ironic how the choice of Java and sandboxing was meant to make this not necessary
  - thezoid 12y ago
    You are comparing apples and oranges. If you are running the same application on equivalent hardware at the same API level then you should be fine. Android has issues with hardware as well as the various API versions. The closest parallel in Java would be comparing a Pentium 4 running Java 1.3 vs some 12 core server running Java 1.7 or something.

kayoone 12y ago

In web programming it's especially complex imo. Take a new programmer that can program basic stuff. He wants to learn server side programming and suddenly needs to setup a bunch of servers(vm, vagrant or docker) , needs to learn git, needs to learn how a framework works because you don't want to teach spaghetti code. Then there's html5, Css and probably some template language and a lot of js in modern apps. Add less, sass, coffeescript testing, rest, a js framework and websockets and you have a totally overwhelming setup which is the standard for most apps today.

jimmaswell 12y ago
>He wants to learn server side programming and suddenly needs to setup a bunch of servers(vm, vagrant or docker) I didn't use any of those things while learning web/server programming. Just a laptop with Debian and Apache installed.
dllthomas 12y ago
You don't generally need to "setup a bunch of servers" when you're first learning web programming, and a "new programmer that can program basic stuff" can hopefully already use git - counting that as part of "web programming" as distinct from other programming is hugely disingenuous (git was created for programming that was not web programming). What's left isn't trivial, to be sure, but I don't know that it's harder than getting set up to do development on a microcontroller. More languages are involved, but languages are rarely the hard part.

conductr 12y ago

This is why I recommend all "learn to code" people to start with PHP

virmundi 12y ago
My issue with your advice is that I then have to trouble myself with learning Apache or some similar server stack. Last time I worked with Apache, over 10 years ago, it was annoying, to say the least. What we need is a simple solution. I recommend bottle or flask. Documentation is available. Easy to start. A good community to work with for learners. Will it scale? To Hell with that. No beginner should have to worry about that. They need to worry about first principles. Then work their way up.
- conductr 12y ago
  virtualenv and deployment are why I don't recommend python for step 0 beginners Most people I've talked to at this level, they are so far away from being "technical" that HTML/CSS is already a huge (unavoidable) hurdle and the simplest thing I can imagine is PHP + FTP. If they get on an FTP client that mimics the GUI of a folder system, people get it real quick - they are copying this local file to another folder on the server. To me, the quicker you can get them to deploy something the better. because the first steps are to understand how information is sent to your app, understand that it's your apps job to make sense of that information and return a response. I also tell them to get a cheap standard shared host, so most of the apache is transparent to them anyways. When they get to the point of needing to customize apache, that's an incremental step from where they have already gotten

rainer89 12y ago

In theory that tools that the article rage about are designed to help us to solve problems , make us more productive and help us to make more money.

krschultz 12y ago

I hear him on the added overhead of build tools, testing tools, ticket trackers, code review, and the like. They have their place, but I wouldn't describe them as 'fun'. But for me, Git is integral to writing code. I couldn't image writing code without version control. Git makes experimenting risk free and encourages me to try things and move quickly. There is no risk of breaking anything because you can always go back to the previous working state. There are other tools that are surely just as good or better than Git, but I'm pretty convinced it is a 40 year technology, much like Unix or Vim. It's worth the time to get really, really good at Git. I see it no differently than learning how to use a decent text editor.

billmalarky 12y ago
"Git makes experimenting risk free and encourages me to try things and move quickly. There is no risk of breaking anything because you can always go back to the previous working state." Having built a large project without version control I can safely say git is the best thing to ever happen to my coding productivity and enjoyment. Without version control my anxiety goes through the roof any time I have to work on a large codebase.

clarry 12y ago

Is there something to back up the claim that you must use git and a popular bug tracker to get any community involvement?

falcolas 12y ago
git, mercurial, svn, cvs... different names for the same tools and challenges.
- clarry 12y ago
  > But if a potential contributor wants to fork your code, you'd better understand pull requests, branching and merging, and a whole series of other operations that might or might not have counterparts in the SCMs you've used. I don't think these tools are all the same, at least as traditionally used. And you don't have to (ab)use all their features. Also, you don't have to use these tools at all. But the original author more or less claims that you have to use git to get any community involvement.
  - falcolas 12y ago
    I read it as github being the most popular example of that type of tool. If not github, then SourceForge, or code.google.com, or launchpad, or... the list goes on. And whatever community you ascribe to, you'll have to learn how to operate within it to get community contributions.
    - clarry 12y ago
      I guess such communities exist, but it looks weird to me. It shouldn't be like that. I mean, your project's community should consist of people who use or are interested in using your code. Whether it be hosted on github, launchpad, your own yourproject.com or another server capable of hosting the project. Hosting it is technical details; people should come to the project for what it is, not for where it is hosted at. Therefore the community shouldn't be "github community" or "sourceforge community" or whatever. Or did you mean communities such as "git users", "cvs users" and so on? I think that's still the wrong way to think of it. It sounds like a religious cult formed around specific tools. They're just tools. I shouldn't need to ascribe to "vim community" hosted on "vimhub" even if I wrote my software using vim (I don't).

ixtli 12y ago

I am wholly in favor of writing tools that do one thing well and make it a priority to get out of your way. That said claims like "Git is that it's a whole subworld on[sic] to itself" seem absurd in this context. Perhaps this is the authors problem in general: the trick to productivity is being able to quickly reach functional understanding of a tool/library you've decided to use. Enough to 1) evaluate the tool/library itself and 2) use it in a way that's at least somewhat conformant to how the authors intended. Obviously doing these two things requires good authors and good client programmers. However, if being a large body of work kept developers away from things you certainly wouldn't have a zillion apps on the iOS app store.

clueless123 12y ago

I just want to paint said Michelangelo.. but now I spend all my time mixing paint and building scaffolding and such.. SCM,Frameworks and such are part of the price we pay to be able to build larger and larger projects.

mynegation 12y ago

Oh the irony of an analogy... The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places (once you are set up, that is). Version control, build systems, compilated makefiles, testing frameworks, profiler sessions, deployment scripts - all that takes time to set up, but pays handsomely on all projects of non-trivial size and length. The right thing to do is not to get rid of this "overhead" but make this setup as easy as possible.

deleted 12y ago
[deleted]
TheCraiggers 12y ago
>The point of these complications is that you are able to travel farther and faster on a jumbo jet than on a bicycle and these journeys will take you to many more interesting places That's a rather insightful thought that I didn't think of while reading the article. Keeping the analogy going, I'll point out that there is a large difference between bike riding and jetting around the world. As far as traveling goes, one could think of bikes being analogous with enjoying the journey, and flying being analogous with enjoying the destination. Despite the fables and memes, enjoying one over over the other isn't inherently wrong in my opinion, but different people will prefer one over the other. Some people will prefer the simple act of creating something with your own hands using (relatively) simple tools. Like a craftsman building a nice table. Others will prefer huge projects, the skyscrapers and the like. When I first read the article, I was only thinking of the one side, but your post has helped me see that creativity takes many forms.
- nmrm 12y ago
  I have another apt application of this already-stretched analogy, but I think it works well w.r.t. the pain of doing large projects without the right tools: A bicycle ride to the next town is enjoyable. Paddle boating across the Atlantic gets old fast.
sebcat 12y ago
I really like the go(1) approach of testing and profiling, and together with Docker and git it really makes for a easy-to-setup environment. Library-first (as opposed to framework-first), write your foo.go and foo_test.go, run go test -bench ., iterate, deploy to devenv, run integration tests, push to live. Works great, no hassle.

andyjohnson0 12y ago

Tim Bray recently wrote [1] about feeling "stuck and discouraged" by complex tooling and frameworks. Excerpt: "In fact, for every hour I’ve put into actually fiddling with Java code, I’ve invested another fighting git submodule subcommands, and now I’m staring at what feels like a thousand-meter-high Gradle rock-face." "I should count myself fortunate that I’m not building a browser-based app; I’d have to budget an even higher proportion of the time staying on top of this week’s funkiest new JS libraries and scrambling to have Wave effects before everyone has them and they’re boring." He also links to Ed Finkler’s "The Developer's Dystopian Future" [2] which was on HN a while ago and addresses the same topic. [1] https://www.tbray.org/ongoing/When/201x/2014/07/17/Discouraged-Developer https://www.tbray.org/ongoing/When/201x/2014/07/17/Discourag... [2] https://the-pastry-box-project.net/ed-finkler/2014-july-6 https://the-pastry-box-project.net/ed-finkler/2014-july-6

_pmf_ 12y ago
From the instigator of XML, which is generally respected as beacon of simplicity, straight-forwardness and common sense[1]. [1] http://en.wikipedia.org/wiki/Billion_laughs http://en.wikipedia.org/wiki/Billion_laughs

pjc50 12y ago

There's a lot to be said for reducing the "time to first results" for people getting started on a platform, whether that's absolute beginners or people retraining to the new trendy thing.

dsugarman 12y ago

I agree with the concept that no one wants to deal with the overhead that comes with working on a distributed product or team, but tools like git have largely reduced the complexity and allowed programmers to get back to coding. without build scripts, you will spend a lot more time outside of coding.

badman_ting 12y ago

I worked at a place that had people whose responsibility was the workflow, precisely so that developers could focus more on writing code. Then people started doing their own projects (good) so they wouldn't have to use .NET anymore (good) but they never took the time to get the workflow right (bad) and each new project worked slightly differently or was built on a completely new and different platform (bad) so now everyone has a more complicated workflow than they used to, and they're all different. No automated testing, no CI, no reasonable way of deploying code and certainly no rollback, who has time for such frippery? I left.

michaelochurch 12y ago

I remember, during a short-lived consulting gig back in 2012, trying to convince a company to use Scala. They panicked about the lack of IDE support and refactoring tools. "IDE support is immature." Response: well, true, but you don't need an IDE. Java makes IDEs mandatory because it's a crappy, verbose language. Scala doesn't. Clojure especially doesn't. Haskell doesn't (although convincing that company to move off the JVM would have been impossible). "Where are the refactoring tools?" Response: when you have good static typing, the compiler is far better at enforcing refactoring safety than any tools on the market. (Java itself combines the worst of static and dynamic typing.) People-- especially non-programming managers-- have become dependent on the trappings of productivity that they've forgotten what actual work looks like. Java culture is full of this nonsense. The business becomes so dependent on a convoluted toolchain that it doesn't need for most purposes. Then there is the myth of the "full stack developer". It's a good idea in theory, but no one knows what it means. It's just management "at the end of the day, it's all about leveraging our core synergies" bullshit. What's really going on is that execs and professional managers can't evaluate the work in most specialties, so they've decided to pretend that specialties don't exist. All types of programming get thrown together into "it's all code; just make the thingy work" and what that means is that programmers get stuck cleaning up any kind of technical mess they have the bad fortune of having thrown to them. The result is that a good number of programmers (those who aren't savvy enough to play the game and be selective in what work they do) end up learning a bunch of crappy, parochial, non-transferrable "how we do things here" details but (a) never get a coherent career or develop the ability to protect a specialty, and (b) are constantly learning "new" but ill-thought-out and incoherent things. For what it's worth, I used to think that this was a "new" problem, or a symptom of the industry getting worse. I'm not so sure that it's very new. Maintenance programming, 20 years ago, was the same slog that it is today. If anything, the situation is getting better. I agree that Git is not user friendly at all, but the damn thing works, and it's far better than other VC tools (e.g. Perforce).

pnathan 12y ago
Great point. Many devs won't touch a tech stack that doesn't have tons of tooling and lots of ceremony possible. (To those used to such things, you will find something tremendously freeing if you drop down to using no language specific tools but the compiler/interpreter).

mzarate06 12y ago

I agree with the overall point: tool complexity can be a major downer and impose residual drag throughout a project's life cycle. I too "just want to code". However, I don't agree with some of the author's examples. Git has proven to be rather simple, minus the initial 1 week learning curve (of casual use, give or take). I use it in solo private projects and in teams. Branching and merging, in particular, are part of why I love it so much; much better than the CVS and SVN days. And isn't using SCM considered a best practice? I think so, but I'd be interested in hearing any counters. I also find build tools essential. Even for web apps, simple ant scripts that automate remote tasks have proven invaluable, especially wrt deployments.

mmphosis 12y ago
And now you have two problems. What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" where someone outside or most likely inside the CDN (our competitor) will take it. There are a lot of things deemed best practice. Best practice for who? And, to what end? Here is a best practice: release developer tools for your platform that are the only way to build software for your platform. Locks in developers to your platform. Makes it difficult to switch or port to other platforms. Enables ways to thwart competitors, by slowing down their development cycle or even stopping it at the approval point. Enables ways to steal ideas and even code. Why do you think each major platform has their very own programming language and plethora of platform specific APIs? A floor of moving snakes is not much fun. One vendor even called their platform ASP. Simple build tools. The ant script is simple, but installing ant is not. And, we don't really want ant and the dependencies it requires. But, whatever works for you.
- mzarate06 12y ago
  > What if the source code needs to be maintained internally? Our source code cannot be stored in "the cloud" ... Then move your SCM server wherever "internally" is? SCM does not require "the cloud". Regarding ant not being simple to install ... would you mind elaborating? I've installed ant a handful of times, either via "sudo apt-get install ant" or as a plugin to my editor; both ways were simple IMO. And I agree with simplicity, particularly with dependencies. I mentioned ant off the cuff, though I also use shell scripts when I can. They handle most remote tasks I can do in ant, but w/a smaller foot print.

codingdave 12y ago

One key is to stick with a toolset long enough to work out all the kinks and become effective with it. Constantly churning your tools leads to frustration. Everyone also has their own preferences. The author was stating how much harder a web app is vs. a mobile app, but I find exactly the opposite to be true. Just pick your tools, learn them, get good at them, and then code for a long time before changing. Don't get caught in the trap of always needing to try the newest thing. Focus on your core purpose of delivering a product, and you'll find that even a non-ideal toolkit still gets the job done, and you can stick with it for quite a while.

gfodor 12y ago
Exactly. You always have a choice, most of these things can be punted on. For example, I continued to use svn for many years before transitioning to git, despite everyone around me saying how great it was. It was a tradeoff, I am happy to know and love git now but at the time I wasn't ready to add that to my plate of complexity. In the end, I was able to focus on shipping sooner instead of learning a new SCM. The trick is learning how to recognize when something is no longer a fad but a true shift, and git eventually became obviously that, so I took the time to learn it. I think the ThoughtWorks Radar is a good resource for this type of thing: http://www.thoughtworks.com/radar/#/ http://www.thoughtworks.com/radar/#/ The assumption in this article is that you always have to be using the latest whiz bang tools and platforms, but that's up to you -- the "fashion" aspect of software development is the problem, not the tools per se.

Roboprog 12y ago

My own pet peeve is Ant/Maven. Sooooo complicated to do so little more than Make. (Running on Windows instead of *nix isn't worth much to me, personally)

colanderman 12y ago

This is why I have side projects. My SCM is Darcs (ridiculously simple); I don't use an IDE, only a text editor; I build with Make or by throwing all the source files at the compiler; I test sparsely by hand; and I deploy only to my own client and server so I don't need a configure script or any JavaScript feature-testing madness. It's wholly unsuitable for anything professional, and it's wholly a joy.

trevor-e 12y ago

Most of this article is hyperbole. I work on a large Android application, and while there's some overhead the majority of my time is spent coding. Look at any other engineering discipline and the overhead they have to deal with for their projects. Overhead is intrinsic to any large engineering project. As programmers we are actually spoiled with the fast feedback loop available to us. Learning all the tools is part of the trade. Yes, it can be a pain to do everything, but these tools wouldn't exist if they didn't produce some sort of net gain.

billyhoffman 12y ago

"Premature optimization is the root of all evil... and tools are just another optimization." -Me, ripping off Knuth The vast majority of tools exists to optimize and scale your time. Very few tools beyond a compiler/linker are required for software development. Depending on the size of your project, taking the time to learn a tool or set it up may not be worth it. Setting up build scripts and CI systems may be totally stupid for one project, and essential for another. The trick is to know when it makes sense to optimize your workflow and manual tasks with tools.

ionrock 12y ago

At some point I think it is important as a programmer to take pride not only in the result of the code, but the code itself. Efficiently managing a project can and should be rewarding as well. Developer usability is a very important feature. As a programmer, we write and iterate on code until it is ready to be published to the upstream repository. Our tooling has come about to help take our rough and ugly hacks and massage them into well written code we can be proud to push. Also, banging out code is overrated. I've found that when I take time to think, my actual coding becomes closer to what you see in the movies. I can find my flow and quickly materialize my ideas, and most importantly, solve the problems that arise. When I try to just "code" it ends up being poorly designed and written. The point here is that when you do have the desire to "just code" take a step back and consider taking pride in the code you publish. The tools and systems in place are there to make you a better code publisher. The goal is to write well written code that others (including yourself) can maintain. Rather than being frustrated you have to deal with the intricacies of rebasing or 3-way merges, take a moment to understand these skills will help you publish better code.

stinos 12y ago
When I try to just "code" it ends up being poorly designed and written. this. Not really important for small and/or personal projects, but for anything beyond that simply spitting out code ends up in a bad design violating SOLID and everything else out there, more often than not. After I figured that out, "code" now actually for me means something along the lines of "think about how components should cooperate with a minimum dependency, [enter rest of SOLID and everything else out there here], then start spitting out the tiniest functional pieces needed to implement it from the bottom up". Might not work for everyone, but it has done wonders for me. Especially the more my knowledge/experience about the first part grows (i.e. thinking about design upfront), the better the second part (i.e. spit out actual code gets), and the more proud I am of it. Heck, code from past two weeks is actaully a new personal record for me. So beautiful and well-cratfed :]. Then again, I thought the same thing about a piece I wrote 6 months ago. And the same goes for the way I use all other tools in the build process actually.
mattgreenrocks 12y ago
The desire to "move fast and break things" keeps you firmly in the 1 year of experience repeated 5 times camp. They teach you to overvalue tools like frameworks and languages and undervalue your use of them. It reinforces a consumer notion of technology, whereby you passively play in conceptual sandboxes constructed by The Great Framework Authors. "Just use Rails!" you hear, ignoring the small voice in your head wondering if all of the beauty of computation can really be foisted into ill-chosen paradigms. The cognitive killswitch that is mass acceptance and cultural success overrides that voice, though, so it's all good. Then, when you inevitably get things into a mess, you consult the inevitable cottage industry of people who give you tricks to ward off the pain temporarily.

TeMPOraL 12y ago

I feel his pain. This trend starts to seriously scare me. So the other day I wanted to learn a JavaScript client-side MVC framework. For various reasons I picked Ember. Suddenly, I had to spend a day playing with... Node.js (hey, I was trying to do client-side work!). Hundreds of megabytes of tools and libraries; package managers, web servers, a half of an operating system, just to generate a Hello World example in the way Ember documentation says is right (I also skipped the Ruby on Rails part). An example that, generated, had literally tens of thousands files and directories. Now the question is, why on Earth do I need to install Node to play with client-side JS (that is supposed to work, like, in browser)? Why do I need to subscribe to a particular TDD-ish development regime? Why every project nowdays uses a random build tool written in/for completely unrelated programming language? I've recently seen C++ code for AVR being compiled and loaded by Scala build toolchain. I get that some of this may be useful in large multi-team projects. But for small code written by one or few programmers? I feel it's only a distraction. I smell cargo cult.

collyw 12y ago
Is it my imagination, or is this problem fairly JavaScript centric?
- TeMPOraL 12y ago
  I don't think so. More like webdev-centric (everything nowdays uses random build and test tools that are not necessarily in Node - sometimes it's Python, the other day it's Ruby...), but then again while working in an Erlang shop some time ago I went through two different build tools (one of them was made for Ruby libraries, btw.). And don't get me started about Java.
  - mattgreenrocks 12y ago
    The webdev stack is so, so bad. It gets an enormous pass because programmers love programmer culture, and it's open. (Exactly like the lackluster Linux of the nineties being immune to criticism due to openness). You know what a great workflow is? Vim, C, and a Makefile. C offers a far more conceptually complete model that isn't forced client/server. The C compiler does basic checks on my code (revelatory, for sure), and the Makefile, as horrible as the syntax is, can be added later. If I'm teaching someone, they can open something like gedit, type some code in, and run gcc manually. Boom! A program to run!

levifig 12y ago

This might sound crazy, but I'm on the "other side" of this conversation: I'm incredibly passionate about the management side and "shit umbrella" functions of software development. I'm driven by helping make sure developers can do what they love and do best: code! :)

webmaven 12y ago

"Having fun, yet? We haven't even begun to code." Whoah, waitaminnit... At least some of those decisions can be deferred if you like. You've decided on Git or some other SCM you're more familiar with. OK, fine. Nothing stops you from using it locally and deferring your decision on where to put a shared repo until later. Same goes for ticket tracking, continuous integration, testing, and so on. And if you want, just skip them for now. Heck, if you really want to, you can even defer using an SCM. Nothing is stopping you from starting your project, building it privately, sideloading it into your personal device, and deferring almost everything else infrastructure-wise until later. Yes, if you are building for iOS, you need XCode. If you are building for Android, you probably want Eclipse. But that's about it in terms of required infrastructure. You almost certainly can 'just start coding' if you want to. In fact, given that it is smart to 'build one to throw away' anyway, starting out by avoiding the initial overhead isn't necessarily a bad idea.

gavanwoolery 12y ago

I do agree with the author a bit. It's not that all these toolchains are useless (they aren't) -- its just that they should be a far more invisible part of the process than they are. The pinnacle of this frustration was when I used to contract native iOS apps. The sheer amount of crap you have to crawl through to do something nontrivial is ridiculous - and I'm not even talking about getting into the app store. This is one reason I started to fall in love with javascript. I've been a longtime critic of the language, but I'll be damned if there is not an easier way to build, test, debug, and distribute code. Growing up, I learned from MS QBASIC - which was an incredibly easy portal into coding. It is a shame no such things are commonly available today.

recursive 12y ago
I started with QBasic also. Things like that still exist. See http://plnkr.co/ http://plnkr.co/ and others.

ErikRogneby 12y ago

Programming small memory footprint embedded systems still requires you to figure out how to pedal that bike the best you can.

egypturnash 12y ago

I think this is something that happens to any field. I trained as a 2D animator. When you start, it's great - there's just you and the drawings. You can make anything happen. But once you start to want to make something bigger than a couple of seconds, things get complicated; you have to plan a script, wrangle multiple scenes, start involving other people to break up the process in various ways - inbetweeners fill in frames between what the lead animator draws, cleanup artists neaten things up, colorists, background painters, 3D people for stuff that's a pain to do by hand... plus all the non-drawing support people. Watch the credits at the end of any animated feature. All of them. Every single one of those people put in a lot of hours to make that film happen; not all of them did work that shows up directly on the screen. But all of those people had an important part to play, and all of them had to have ways to communicate with each other. I burnt out on that because I didn't want to be a cog in a machine designed to tell stories to the largest possible market. Now I draw comics. And guess what? I've got to deal with learning how to put together a website, put together a book for print, promote my work, go to conventions and sell stuff, etc. It is just barely doable by one person; I've been spending three years doing a ~400p graphic novel by myself, and I've got about a half a year left before it's done. I have template InDesign documents, scripts to help fill those templates, friends willing to try to make sense of the in-progress work and tell me when things don't make sense, sprawling directory structures full of source files and web/print res files, sketchbooks full of planning, etc etc etc. It helps that I was already able to wrangle a website; I'm slowly turning my custom templates into something anyone who wants to present a comic online the same way I am can use. If I wanted to start telling a lot more stories a lot more quickly, I could start parallelizing: separate the job into writer/artist/colors/lettering, find an existing publisher willing to handle packaging/printing/distributing to comic stores, bookstores, and e-stores, as well as shop it around to Hollywood. I can knock out a nice standalone drawing in a few hours. I still do that every now and then when I need a break. But my aspirations are higher; I want to create a world for the reader to inhabit for a few hours. And that takes a lot more work. Every kind of complex project has its own kind of scaffolding that users of the final project will never see.

raverbashing 12y ago
That's a very nice example, thanks for sharing. Good process makes your work of being "a cog in the machine" much more easier (and abstracts the rest for you - and of course, your work will be abstracted away for other people)

FrankenPC 12y ago

Personally, the scaffold doesn't scare me. It's the fact that the scaffold moves with regularity.

FrankenPC 12y ago

Personally, the scaffold doesn't scare me. It's the fact that the scaffold moves with regularity.

wpietri 12y ago

The false comparison here bothers me. Sure, back when I learned to code I could just type some stuff in on the machine in my basement, type "RUN", and have magic happen. Yes, it was stuck in my basement, and it couldn't do much, and it wasn't connected to anything. And yes, it could do exactly one thing at a time. But it was still pretty magic. This guy wants the same experience when building for a computer a million times more powerful, one that fits in his pocket. And he'd like to access a global network of satellites that shout timestamps so that he can, in real time, calculate his precise position and then record it. While that computer continues to do all the things that he expects of it, like letting him take phone calls and receive email from anybody in the world while playing whatever song or movie he'd care to watch. Oh, and he'd like other people to be able to run his app, suggest improvements, view his source code, and offer fixes. I think it's great to want things to be easy; that sort of irritation is what drives us to make better tools. But a big problem here isn't that the tools are overly complex, it's that he wants a lot more than he did 30 years ago.

ternaryoperator 12y ago
Not sure I see how that's a false comparison. What does the additional capabilities of the platform have to do with the incremental amount of yak shaving? You're implying that the notoriously tedious Android builds are the result of the phone's underlying prowess? Maybe they're difficult because the tools used are balky.
- wpietri 12y ago
  It's not the complexity of the platform as such, it's the complexity of the desired result. If he wanted to write a little C and burn it to a simple, tiny, single-purpose computer that he just used himself, the toolchain for that is still pretty straightforward. I'm sure the tools could be improved. But I think he should acknowledge that a simple developer experience 30 years ago was simple because his desires were relatively simple. (And because the tools had been polished enough that simple desires were simply accomplished.) What he's asking for is more complicated. Should the tools mainly hide that complexity? Sure. But that doesn't come for free.

epaladin 12y ago

No one is stopping anyone from writing applications by themselves and distributing them by standard installation packages on a website, like what has been common since about 1995. No one is forcing you to set up an open-source project with distributed source control. No one is making you deploy on the app stores. Those are complex systems, and so it's no surprise that setting them up is non-trivial. Learning about Git is almost certain to be simpler than re-writing something Git-like every time you want a DVCS. Submitting to an app store is probably easier than trying to get your program listed in every software directory that exists for a given platform outside of that app store. Of course these things can be simplified a bit, and likely will be, but I think the current state of things is expected as part of the transition to new models of collaborative work and software distribution.

mcguire 12y ago

> ...now so overwhelms the developer experience... Now? This is not a new sentiment. In fact, it's older than I am. That may qualify it as a cliché.

hectip 12y ago

This isn't the internet we were given. This is the internet that we lost. Everything is locked down. Web pages with more style than content. ISP's capping upload speed, preventing me from running a small home server.

CmonDev 12y ago

This is my problem with Unity3d. Just like XNA, they picked a very good language (C#) but then they reduced it to scripting. So basically creating an app became just integrating pre-made chunks of third-party scripts/binaries + some assets from the store sprinkled on top. Furthermore it forces their architectural vision of what components and entities are about and there is no customization available on lower levels.