
Just let me code - TheCraiggers
http://www.drdobbs.com/tools/just-let-me-code/240168735
======
mynegation
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.

~~~
exDM69
> 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.

Part of what the OP was trying to say is that these tools sure are valuable
and necessary in all non-trivial projects, but you can't get away without them
even if the task at hand is trivial. Like the simple mobile app that the OP
was talking about.

Once a project grows too big to be one or two source files, you're going to
have to invest time to set up version control, build systems, testing,
deployment, etc. It's like you'd have to take the jumbo jet to go to the
grocery store and not being allowed to ride a bike.

I recently went through bootstrapping a project like this, I had been working
in a single C file in Vim (:setlocal makeprg=gcc\ -o\ %:p:r\ %:p $CFLAGS)
which was rather nice and I was very productive initially (and enjoying
myself). Now I've spent about 5 working days setting up builds and automated
testing, test coverage, profiling, continuous integration, etc and I'm still
not done. That's 5 days worth of time not going to solving a problem.

~~~
tdumitrescu
It's your personal project; no one's forcing you to use version control, a
non-standard build system, etc. Many of us spent many years/decades coding
without, and personally I never never never want to go back to working that
way. It's the standard tradeoff of automation: some extra time up front
learning and setting up some workflow tools (download them, write your own
scripts, whatever) ends up saving you from an absurd amount of repetitive,
error-prone manual activity.

~~~
exDM69
> It's your personal project; no one's forcing you to use version control, a
> non-standard build system, etc

This is simply not the case any more. If we go back to the example in the OP -
a trivial mobile application - even if the _code_ would fit in one simple file
and would take no longer than a few hours to write, doing all the mundane
setup work would still be there. You can't build an Android or an iOS app
without using the toolchains the platforms provide. You're going to have to
write XML manifests and build scripts and whatnot (and/or learn the respective
preferred IDEs for _both_ of them).

The same applies for any practical sized application, no matter how simple.

> personally I never never never want to go back to working that way.

Me neither, I just wish the overhead of setting all this up would be less.

Now the best thing we have are language-specific tools and conventions, no
universal established best practices exist. This is also why "Java shops" hire
"Java Programmers" and not C# programmers. A proficient programmer in either
should be up-to-speed on the other in no time if it weren't for all the new
tools that have to be learned.

~~~
pekk
> You can't build an Android or an iOS app without using the toolchains the
> platforms provide.

That's because of the way Android and iOS were designed. The amount of crap
around coding is not a constant, it's very easy to inflate it with things like
XML manifests and IDEs.

------
erikb
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
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
>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
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.

~~~
karmelapple
Equivalent hardware in the Android universe is the Nexus 5 (plain Android UI),
Samsung S5 (using Samsung's UI customization, TouchWiz), HTC One M8 (Sense
UI), and Moto X (almost plain Android UI, but not quite).

So a closer parallel would be that 12 core server running Java 1.7 can have
its UI skinned by different device manufacturers, and that the UI actually
makes a great deal for acceptance of the app in the marketplace.

------
ionrock
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.

~~~
mattgreenrocks
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.

------
egypturnash
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.

~~~
agumonkey
About scale (in programming)
[https://news.ycombinator.com/item?id=8072730](https://news.ycombinator.com/item?id=8072730)

Similar patterns, short is exciting until you hit the next complexity wall.

------
wpietri
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
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
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.

~~~
Gormo
The complexity of the platform's capabilities and the complexity of the
toolchain don't seem to be necessarily related to each other; in fact, by
pointing out the sophistication of the platform, you're sort of making his
point for him. Writing a GPS mapping application for the Commodore 64 would be
a vastly complicated undertaking, but writing one for a modern smartphone
should be trivial precisely because the phone has an integrated GPS module and
the processing power to parse its output in realtime without having to
implement a vast set of hacks and optimizations. The point is that relative to
the platform's capabilities, his desires _aren 't_ any more complex than those
of the basement coder on a C64 thirty years ago, so why does he need to
contend with excessively complicated development and deployment tools to
implement them?

~~~
wpietri
Even if I grant that his desires aren't more complex relative to the platform,
that doesn't help, because the platform is enormously more complex.

But his desires _are_ more complex relative to the platform. He wants to do
open-source development with distributed version control and collaborative bug
tracking. Try that on a C64.

Further, the C64 was a consumer device, carefully engineered to make it easy
for novices to a constrained set of basic stuff. I agree that we should have
Android development tools like that. Sort of a Logo or Visual Basic for the
modern age. But the current mobile tools are for professional developers to do
complex, professional things. That's because they mostly want to make
complicated, highly polished, consumer-friendly apps.

Those tools may _also_ be needlessly complex for the purpose, and I think we
should fix that. But we won't do that if we can't acknowledge the essential
complexity of the domain. As Einstein wrote, "Everything should be made as
simple as possible, but no simpler."

------
krschultz
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
"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.

------
andyjohnson0
Tim Bray recently wrote [1] about feeling "stuck and discouraged" by complex
tooling and frameworks. Excerpt:

 _" In fac­t, for ev­ery hour I’ve put in­to ac­tu­al­ly fid­dling with Ja­va
code, I’ve in­vest­ed an­oth­er fight­ing git submodule sub­com­mand­s, and
now I’m star­ing at what feels like a thousand-meter-high Gra­dle rock-face."_

 _" I should count my­self for­tu­nate that I’m not build­ing a browser-based
ap­p; I’d have to bud­get an even high­er pro­por­tion of the time stay­ing on
top of this week’s funki­est new JS libraries and scram­bling to have Wave
ef­fects be­fore ev­ery­one has them and they’re bor­ing."_

He also links to Ed Finkler’s "The Developer's Dystopi­an Fu­ture" [2] which
was on HN a while ago and addresses the same topic.

[1]
[https://www.tbray.org/ongoing/When/201x/2014/07/17/Discourag...](https://www.tbray.org/ongoing/When/201x/2014/07/17/Discouraged-
Developer)

[2] [https://the-pastry-box-project.net/ed-finkler/2014-july-6](https://the-
pastry-box-project.net/ed-finkler/2014-july-6)

~~~
_pmf_
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)

------
billyhoffman
"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.

------
danso
> _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.

~~~
knowaveragejoe
> 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.

------
codingdave
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
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.

------
clueless123
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.

------
hyperliner
"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
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.

~~~
codingdave
It does get there already, in some places. I've been in large organizations
that have a build person, a source control person, etc. They take care of it
all, so the coders can "just code".

Those environments have totally sucked, because to pigeonhole people into
those roles in the first place requires a non-flexible, non-creative culture.

There is a proper balance to everything, but few organizations succeed in
finding it.

~~~
jimmaswell
>a source control person, etc. They take care of it all, so the coders can
"just code".

What do you mean a source control person, just someone who manages the source
control when it goes wrong? The programmers are still doing the committing,
pushing, pulling, branching themselves

~~~
codingdave
Committing yes, everything else no. The source person managed the servers,
branched and merged as necessary, and oversaw the build processes to be sure
we had good dev, test, UA, and prod deployments at any given time.

She hated that job, BTW. :)

------
webmaven
_" 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.

------
epaladin
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.

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

------
kayoone
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
>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.

------
TeMPOraL
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
Is it my imagination, or is this problem fairly JavaScript centric?

~~~
TeMPOraL
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
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!

------
dsugarman
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.

------
ixtli
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.

------
gavanwoolery
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
I started with QBasic also. Things like that still exist. See
[http://plnkr.co/](http://plnkr.co/) and others.

------
mzarate06
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
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.

~~~
pimlottc
> 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.

It sounds like you are mixing up Github with Git itself? You don't have to
host your code at github to use git. It's just one of the more popular ways
for open source projects.

> The ant script is simple, but installing ant is not.

It isn't? Ant is packaged in most major distros; what kind of servers do you
normally deploy on that doesn't have it?

------
badman_ting
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.

------
trevor-e
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.

------
pjc50
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.

------
CmonDev
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.

------
colanderman
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.

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

~~~
rmetzler
If you want the community to be involved with your code you should use what
the community use. For a lot of languages today this is git and GitHub.

~~~
clarry
But is _the community_ so narrow-minded today that it won't bother if your
project doesn't use their favorite hosting provider and version control?
Before this git religion, I think it was normal for everyone to accept and
live with whatever tools the project they want to get involved with used. And
there was more variety as to where projects would host; certainly sourceforge
and the like were popular, but so were projects that hosted themselves.

------
levifig
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! :)

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

------
hectip
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.

------
Roboprog
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)

------
mcguire
> ... _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é.

------
rainer89
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.

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

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

~~~
virmundi
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
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

------
michaelochurch
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).

~~~
hibikir
Back in 2012 Scala already had some decent IDE support in IntelliJ. It's far
better now, as pretty much everything that is supported in Java works in Scala
too.

Clojure is in a different situation though, but that's because its type
system, or lack thereof. Just like in Javascript, people end up falling back
to REPLs and other such primitive tools, because the IDE just can't tell you
very much about your code. Code is data is not a strength, but a double edge
sword.

As for Git's usability, yes, it's not very good, which interestingly seems to
be a key reason of why it has so many advocates: it forces you to understand a
whole lot of internals to be proficient at it, and while git's command line
interface is pretty ugly, its internals are elegant. It's kind of the opposite
of what happens with Mercurial: It's easier to start working with it, so
people don't look into it long enough to fall in love and start advocating.

What I really find interesting about this whole 'let me code' thing is that,
while I really don't want to spend valuable mental space dealing with a
complex environment, I do not want to use it instead on code, but on figuring
out what is the right code to write. We obsess over the mechanics of coding,
over our tooling, but what really matters is that we are actually solving the
right problem.

I spent some time this month with some code written by my predecessor at this
job: A well known library designer and speaker. He had looked at a hard
problem, wrote a proof of how to solve it, and wrote a mathematically correct
implementation matching his paper. The problem is that his premises were
incorrect: He failed to account for some unavoidable issues. That made his
last 4 months of work here a waste because he was just solving the wrong
problem.

I want to spend less time coding, and more time making sure that the coding is
actually solving the real problem at hand, not an incorrect idea of the
problem.

~~~
codygman
I think proving your implementation correct can be a great thing after it's
had some time to verify your implementation accounts for issues that come up
in production.

