
Developers who can build things from scratch - orand
http://www.aaronstannard.com/engineers-from-scratch/
======
huuu
I think most commenters misread 'from scratch'. The author is talking about
ideas not about code.

So even developers who can build things from scratch use frameworks when
needed.

~~~
Aaronontheweb
Author here - yep, that's exactly right. Didn't occur to me people would read
it that way (whoops!) - I meant implementing ideas from scratch.

This was inspired by a lecture I gave to some entrepreneurs on Friday (I put a
link to the slides in the post) - these folks are people with business /
design backgrounds who are trying to figure out how to realize some idea
they've been working on. It was part of a larger course they were in - my role
was just to give them the CTO / technical co-founder's perspective on what to
look for in building their early tech team, picking a technology stack, etc...

I ended up really having an intense discussion with them on "finding the
developer to implement an idea from nothing" and tried to capture that in the
blog post.

~~~
kephra
I think most people first think about developers who can not build from
scratch. Those who require frameworks, and can only fill the gaps.

So one trait a from scratch developer must show, is being a toolsmith. Most
startups do not have the time to build everything from scratch. Instead they
have to pick tools to solve their problem. A toolsmith can quickly validate if
a tool is suited for the task, and is able to create new tools if necessary.

So there are few things one can check before hiring a developer: A toolsmith
published his tools, frameworks or libraries. A bughunter contributed to 3rd
party projects. ...

Or in short: A developer who did things from scratch, will be proud showing
them. An this will show where his strong and weak points are. ( e.g. my weak
point is design )

------
hyperion2010
Giant hunters. Not giant slayers, but the guys who have been around long
enough that they have a pretty good idea of which shoulders to stand on if
they want to reach something.

------
alextgordon
I must have been stuck in the HN bubble too long because I'm really surprised
that there's non-technical entrepreneurs trying to start technical startups.
How does that even work?

~~~
ghostbrainalpha
Almost every company will eventually need great salespeople.

A great salesperson with a great idea, can recruit developers to implement the
idea. It's rare, but I've seen it happen.

~~~
BurningFrog
But how does the salesperson tell the good developers from the bad?

That's hard enough even for us _in_ the game.

~~~
PeterisP
I've seen a bunch of products that were initially built by developers who were
totally inexperienced at the time and not particularly good even after all of
that - the codebase was a total mess, but if that initial version had the core
features and somehow works by magic of ducttape, babysitting the production
code and manually fixing data when it gets broken, then it can get rewritten
more or less properly after the concept is proven and the business can hire
better (and more) technical people.

~~~
BurningFrog
But who hires the better people?

Presumably the previous not-so-great programmers, who are now VP of
Engineering. Or do you fire those guys?

------
zkhalique
Actually, in my experience most developers would prefer to build something
from scratch, instead of taking over some codebase.

~~~
cuillevel3
Yes and it's easier too. Well, until your project reaches a certain size, than
it's actually very much like working on someone else's code...

------
Animats
The article seems to be about building routine web and phone apps. There's no
reason to build those "from scratch", and many reasons not to. The tools,
libraries, and frameworks in that area are plentiful. Why re-invent the wheel?

A decade ago I wrote most of the software for a DARPA Grand Challenge
autonomous vehicle. Now that was "from scratch". Almost every file was 100%
new code. There were no libraries for that stuff back then. Unless you're
doing something exotic like that, or have severe performance requirements, or
are producing something for very high volume production, working "from
scratch" seems pointless.

~~~
ci5er
> Unless you're doing something exotic like that, or have severe performance
> requirements, or are producing something for very high volume production,
> working "from scratch" seems pointless.

Maybe. Platform limitations are a thing. And you started out your comment with
the observation that not everything is a web-app.

Way (way!) back in the day, I had to implement SGI's new OpenGL spec on SunOS.
Because it didn't exist, and we needed it for some internal semiconductor CAD
programs. Which is to say: the CAD program developers had SGIs and the rest of
semiconductor design had sun boxes.

You might be doing embedded, or robotics, or process control or field-
monitoring or flight systems, or ... In many (most?) of those, you make a new
directory, fire up vi on a main.c file and go from there. If you are lucky
(and luck seems to improve w/ time, I will admit), you have enough headroom
(space, performance) to do a lot of it in Python. Often not, though...

------
jheriko
i'm not sure these guys are so rare... sounds pretty normal to me. :/

~~~
ak39
Maybe you are one of them! :-)

It's truly rare to find techies who are _more_ excited to see the end result
in the hands of productive and happy end users than they are about the
technology used to build said solutions.

The trait is more a mindset, a philosophy of empathy than it is a technical
skill of building software.

~~~
lawry
I'd like to ask you something.

When working on a project (that may sound boring like a stock-management
system), and during the endless development of this (keep adding functionality
the employer asks for) starting to want to use this system yourself for daily
stuff (hey I have a lot of electronics that could and would profit from a
stock-system to find all my shit).

Oh and on top of that constantly keep having thoughts about how I could
improve the flow and stuff.

Does that fit into that description of "techies who are more excited to see
the end result in the hands of productive and happy end users than they are
about the technology used to build said solutions"?

~~~
Gibbon1
At one time I worked for a marketing guy who was not a coder nor an engineer
really. What he was really good at was closing the loop by talking to people
and asking questions. Because any project you have a bunch of different groups
and white marketing is about getting them to reason collectedly to solve
problems.

So the 'from scratch guy' is a technical person that cares about closing the
loop instead of working on technical puzzles inside his comfort zone.

Me I have two things. I hate working on anything and then have it not ship
(What I could have spent the last three months in Costa Rica working on my
tan? Seriously?) And I like when I see people using the stuff I worked on.
Nothing better than to see that customers are ordering your product and the
company is shipping it and making money without having you to be involved.

------
ibudiallo
It's not that it is hard to build stuff from scratch, it's just that it is
easier to use a tool to do it.

I worked on a project where we had to remove jQuery from the page, and it was
a nightmare for all the developers that had never written vanilla JavaScript.

These days, I don't use jQuery or bootstrap, or lazy loading libraries because
I can just add the functionality I need by myself.

~~~
volker48
Be cautious removing and/or avoiding jQuery. I was once using it for something
very small in a project and I figure what the heck I can just use vanilla JS
for it so I removed it. I then had several bugs because every browser has its
quirks even with very basic JS. I mostly use jQuery not because I can't do it
in vanilla JS, but just because thousands of hours have gone into making code
that will work across different browsers and browser versions.

------
h1fra
actually, nearly all developpers like to build things from scratch. The real
difference is, as noted in the article, the one who will use the right tool
for the job and the one who take "from scratch" literraly.

I see many people, doing 'from scratch' the same things for years just for the
sake of it. Without realizing they are wasting time and introducing the same
bug/mistake because they can't learn anything new. And when you present them
framework, library or snippets, they are reluctent to learn or simply discover
them. I find the lack of curiosity and self questionning very disturbing, for
a community that introduce themselves as rockstars and elite of society.

So a developper that can from scratch is for me, actually less interesting
than a developper that know how to reinvent himself.

~~~
cellularmitosis
Generally, I agree with what you are saying. However, there is one example of
someone speaking to the opposite view which I also agree with: Marcus Zarra:
[https://vimeo.com/97058344](https://vimeo.com/97058344)

I think the key there is that he is in somewhat of a niche: client-side iOS
programming. By limiting the set of problems which he is reimplenting "from
scratch" again and again, he has some hope of getting very efficient at the
"from scratch" approach (he becomes an expert in that approach). I also think
this approach is probably only realistic for very small slice of people (top-
level talent whom are also lone-wolf contractors (no oversight, no
collaboration)).

------
bjacks
A little off-topic, but has anyone else found that a lot of Haskellers fit
into that "pet technologists" category? I've worked with a number of them, and
seen them sneak Haskell in, despite it not being the best choice for the
project.

~~~
jerf
The really weird thing is that the couple of people I've encountered this
problem with weren't very _good_ at Haskell. A big ol' mess of code mostly in
IO, scattered willy-nilly with a lot of code duplication (in Haskell of all
languages!). No pipes, no lenses, unnecessarily partial functions, manual
implementation of things the type system is supposed to do, just bad in every
way. (Not saying you "have" to use pipes or lenses, but you ought to know what
they are and choose not to use them, not have your choice forced by
ignorance.)

And, uh, quite tetchy if I even hinted at the possibility there were better
ways to write that stuff. These people also expect to be the only ones who
know Haskell in the area and are, ahh, unprepared to be wrong.

For what it's worth, don't judge Haskell by these people anymore than you'd
judge any other language by its worst adherents. It may not be The Answer To
Everything (TM) but it is worth some study at some point by any developer
interested in progressing their skills.

------
contingencies
I am definitely 'from scratch' and looking for interesting projects, so if you
need someone who fills this void please do get in touch. What motivates me:
social value, technological boundaries, no bullshit hard and fast artificial
business-technical lines in the business, and remote capable teams (meaningful
contributions and communicative value over idle presence).

------
shams93
Well in a sense you're rarely building from scratch, in that you're using
frameworks and libraries, but what he is talking about is someone who can
build out your MVP. Its really pretty hard I'm in the process of building an
MVP from "scratch", I'm using Meteor so not as gruesome as building a first
product in bare metal C lol but one thing it takes is a manic level of
dedication, forget about balance, the reason this is difficult to find is that
most people expect this level of dedication for like $60-70/hour. If you want
a coder to work that hard be prepared to be offering that person a CTO role,
the work they're doing is so important to offer anything less than that is an
insult, really. But if you're working this hard to own something then the
amount of dedication it takes balances out the equation. Its not so much about
problem solving as it is about dedication and tenacity, problem solving is a
part of the tasks you do, sure but the central requirements are dogged
tenacity and dedication in the face of adversity.

~~~
LoSboccacc
I'm in this exact position. Brought up in a startup with CTO role to build a
complex piece of visual storitelling software.

A thing that miss from the list of competency is to fight thoot and nail
feature creep.

We just released our mvp within a week of the estimate and it was hard to
fight back all the 5 minutes types of addition that came to mind to everyone
on the project.

A mvp is also an idea factory and over excitable folks will be gmtempted to
add loads of stuff before user validation which kind of defeats the whole
scope of it

~~~
fit2rule
Feature Creep means you've got a broken development process - most likely in
the area of writing and approving requirements, and reviewing requirements,
and so on. Never work on a project where the requirements aren't written,
using a standard form and language - and never, ever, accept a verbal request
for a feature - get it into a tracking system so that it can be formalized.

~~~
LoSboccacc
Doesn't really apply to my position tho. I'm the one helping defining and
shaping those. Heck the whole thread is about starting from zero at the point
the mvp is slight more than an idea.

~~~
fit2rule
But that's the point: going from zero (idea) to implemented (software)
requires a few steps along the way, and imho one of those very important steps
is the proper administration of requirements specifications in such a way that
feature creep doesn't happen. I know its not easy: thats why its important.

------
jmspring
Building everything from scratch is a bad idea.

What you should be able to do is look at the needs, break them down, and
communicate (and eventually develop based off such) different approaches based
in the business need.

Honestly, every new project rest api or below, I look at problems as a clean
slate and then weigh other team members, long term plans, quickest path(as
needed), Eric.

I would think most schooled software engineers would have the acumen for such.

