Developers who can build things from scratch | Hacker News Reader

Developers who can build things from scratch

aaronstannard.com

130 pointsorand43 comments

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.

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.

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 )

We built our own framework :)

It was kind of funny because I thought at first that's what he was taking about, but then his message clicked and I agree. No developer should rely on one tool for the job; you have to be open-minded, try out new things, and explore new solutions. Taking this approach in the beginning is rather daunting, but definitely pays off in the long run when you have the ability to tackle problems from multiple angles.

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.

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?

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.

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

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

>>how does the salesperson tell the good developers from the bad?

By reading the linked article?

Well my bet is he give the guy some contract work, and see if he delivers. How you interact with him and how he explain technical problems to you. Then look at the quality of the product he built.

You don't actually need a good developer to build an MVP to sell--you just need a good enough developer to prop up the cardboard cutouts long enough to raise enough funding to hire the right people and get referrals.

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.

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?

Whether this is an effective technique or not, I think they look for people that at seem to really understand the pitched idea, and specifically don't say it's impossible. Probably a similar search technique any of us would use when navigating an opaque bureaucracy looking for help.

It may not be the stuff of unicorns, but there are quite a few niche markets where you might have someone who knows the problem space inside-and-out who may not be a coder. I've seen niche software that does everything from manage a farm to inserting those annoying mini-flyers into monthly mailed bills that you get from utility companies.

I think the Peter Principle has a lot to do with it personally:

https://en.wikipedia.org/wiki/Peter_Principle

I've learned to never work for someone who can't do your job, and that includes "Founders" and "startup people".

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

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

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.

Life is short, work is infinite. Don't make your life harder unnecessarily.

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

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

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.

It's only rare because a) it is undervalued, and b) it is frequently out of the developers control.

Is it weird that I enjoy both?

I can appreciate really nifty code, but I also get very happy to see my code get used by other people.

One is more of an intellectual satisfaction, and the other is more of an ego boost.

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"?

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.

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.

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.

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.

That was my first thought as well... I find it's pretty rare to find a developer that is excited to work on someone else's bugs...

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

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

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.

I asked myself the same question. What is the best choice depends on both stated goals, assumptions, and predictions, which means others might differ in their assessment of the right tool for the job. In this case, why was Haskell not the best choice for the project and do you think those that tried to introduce it would have agreed?

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.

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

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com