
What does it take to be a good programmer? - ingve
https://dimitrov2k.wordpress.com/2017/01/22/what-does-it-take-to-be-a-good-programmer
======
TeMPOraL
My personal advice would be to follow the Ira Glass quote:

> _Nobody tells this to people who are beginners, I wish someone told me. All
> of us who do creative work, we get into it because we have good taste. But
> there is this gap. For the first couple years you make stuff, it’s just not
> that good. It’s trying to be good, it has potential, but it’s not. But your
> taste, the thing that got you into the game, is still killer. And your taste
> is why your work disappoints you. A lot of people never get past this phase,
> they quit. Most people I know who do interesting, creative work went through
> years of this. We know our work doesn’t have this special thing that we want
> it to have. We all go through this. And if you are just starting out or you
> are still in this phase, you gotta know its normal and the most important
> thing you can do is do a lot of work. Put yourself on a deadline so that
> every week you will finish one story. It is only by going through a volume
> of work that you will close that gap, and your work will be as good as your
> ambitions. And I took longer to figure out how to do this than anyone I’ve
> ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just
> gotta fight your way through._

That is, code a lot of stuff. And, while doing so, _pay attention to how you
feel_. Sometimes it'll be exhilarating, or you'll be proud of what you done.
Other times, you'll be confused, or afraid, or pissed off about how something
you wrote earlier is now unmaintainable or hard to make work. This is how you
actually learn the insights behind all the dogmas, rules of thumbs,
heuristics, good practices, etc. That's how you develop taste - that intuition
which will help you write good code.

~~~
optimuspaul
This nails it in my opinion. Too often I see people assume that
programming/coding is somehow science based. It's not really, it's an art and
you need to be a creative person to be good at it. The science comes later
(sometimes never for some).

~~~
loafa
More of a craft than an art. Sometimes it's more like woodworking, sometimes
it's more like plumbing, but it's rarely anything like painting.

~~~
cynwoody
Some years ago now, I came upon a lovely essay entitled "Hackers and
Painters†". Here is how it begins:

    
    
        When I finished grad school in computer
        science I went to art school to study
        painting. A lot of people seemed
        surprised that someone interested in
        computers would also be interested in
        painting. They seemed to think that
        hacking and painting were very different
        kinds of work-- that hacking was cold,
        precise, and methodical, and that
        painting was the frenzied expression of
        some primal urge.
    
        Both of these images are wrong. Hacking
        and painting have a lot in common. In
        fact, of all the different types of
        people I've known, hackers and painters
        are among the most alike.
    
        What hackers and painters have in common
        is that they're both makers. Along with
        composers, architects, and writers, what
        hackers and painters are trying to do is
        make good things. They're not doing
        research per se, though if in the course
        of trying to make good things they
        discover some new technique, so much the
        better.
    

I think he got it right.

†[http://www.paulgraham.com/hp.html](http://www.paulgraham.com/hp.html)

~~~
ardivekar
Paul has an entire book of his essays by the same title, it's a great read all
kinds of programmers. :)

------
keithnz
Well, I've been programming 30+ years.....

I think one of the main things that makes a good programmer is someone who
cares about the final product. Ironically this doesn't necessarily mean you
have to be super good at writing code. I have seen people with what seems
basic coding capability very methodically build some really nice software.
This is because they are very focused on the "end" not the "means". You see
the thoughtfulness of what has been designed in. Sometimes, in the quest of
writing "good code" it interferes with writing good software because the
emphasis becomes getting good at the means to an end above the end itself.

Not to say improving your coding capability isn't of value, but it's done so
you can create even more fantastic things.

~~~
sidcool
Been programming for 10 years and it's distressing how inadequate and
incompetent I sometimes feel. I like to rebuff it as Impostor's syndrome, but
who knows, may be I am just bad and surviving because mediocrity is what the
industry wants.

On the other hand, the pleasure that a good piece of code in a beautiful
software gives is something I can perhaps relate to an opiate high (as a
metaphor, never tried honestly :) )

~~~
CannisterFlux
I find it more like the feeling of having sorted out my wardrobe (folded
things and thrown out old clothes, I hate doing this despite feeling better
afterwards). Or a mix of that and say building a good looking Lego MOC from a
limited set of pieces. But only for some things - I have several self-
contained python scripts that give me this feeling. Sometimes fixing a bug in
a clean way.

Other things - Android apps for example - tend not to give me this vibe. They
feel more nebulous and "unfinished", like it's a miracle they work at all and
will break at any moment in ways I couldn't understand.

------
tabeth
Shocking to me that there are so many articles on this. The strategy to
becoming a good programmer is the same strategy to become good at anything
else.

1\. Identify what it means to be good

2\. Work endlessly towards that aim

3\. Deliberately practice

4\. Decide to refine strengths or squash weaknesses. Do this as frequently as
possible. Make sure you have an accurate assessment of what your strengths and
weaknesses are. (5) and (6) can help with this.

5\. Consult the advice of those more experienced. As frequently as possible

6\. Allow your work to be publicly scrutinized. Do not work privately, the
feedback loop should be as tight as possible to inform (1)

7\. Repeat (1) - (6) as frequently as possible

Do that and you will become better. Guaranteed. Note, this won't necessarily
make you the best. However, it will make you better. Continue this process
until you're as good as you desire. There, of course, are diminishing returns
after a while.

~~~
FLUX-YOU
>1\. Identify what it means to be good

You'll never get a solid definition for a good programmer, and that's the
problem. If we knew that, we would have a list of things to learn and teach
and we could easily make that a standard interview test before giving people a
job. And no one would need to write any more "10 things you need to know as a
programmer" articles.

~~~
Clubber
If you ask other programmers, you will get a bunch of answers. If you ask the
guy who cuts your checks, a good programmer is someone who can solve their
problems and make their business more efficient.

~~~
flukus
The guy that cuts the checks doesn't know if the programmer is sacrificing
long term maintenance for short term problem solving.

------
elihu
I think there's a personality trait that's really useful in programming, which
is to be pessimistic in the short term and optimistic in the long term.

What I mean by that is that you don't expect some thing you just wrote to work
the first time, and maybe not the second or third, and so on. But you expect
that you'll eventually figure it out and it will work.

A short-term optimist would become discouraged by their expectations not being
met over and over, while the long-term pessimist would not be sustained
through the hard parts by imagining how happy they'll be when they made their
thing work.

I think programming either repels people who are short term optimists or long
term pessimists, or the process of learning to code transforms them into short
term pessimists and long term optimists.

------
tim333
I'm reminded of something Splosky wrote:

>The difference between a tolerable programmer and a great programmer is not
how many programming languages they know, and it’s not whether they prefer
Python or Java. It’s whether they can communicate their ideas. By persuading
other people, they get leverage. By writing clear comments and technical
specs, they let other programmers understand their code, which means other
programmers can use and work with their code instead of rewriting it. Absent
this, their code is worthless. By writing clear technical documentation for
end users, they allow people to figure out what their code is supposed to do,
which is the only way those users can see the value in their code. There’s a
lot of wonderful, useful code buried on sourceforge somewhere that nobody uses
because it was created by programmers who don’t write very well (or don’t
write at all), and so nobody knows what they’ve done and their brilliant code
languishes.

~~~
duderific
This boils down to: write code for your peers, not for yourself. I always try
to remember that, and write code that will be easily understood by others,
rather than the cleverest possible way.

------
leshow
Personally I think the most important thing is a thirst for knowledge. There
are plenty of people I finished school with that were much better engineers
than me out of school, but they don't learn in their free time and they've
stagnated. If you love to learn and you put your time into it, you will
continually improve. With time you will run laps around those who don't.

~~~
passivepinetree
Exactly. If you don't have passion to do something, it's really hard to get
better at it.

Obligatory Randall Monroe quote that hits the nail on the head: "I never trust
anyone who's more excited about success than about doing the thing they want
to be successful at."

If you're not passionate or enjoying what you're doing, you're probably
wasting your time.

------
YZF
Here's my take:

\- You need to think a certain way. You need to be able to see how to
translate a problem into something a machine can execute. You need to be able
to switch from the macro to the micro smoothly.

\- You need a certain level of proficiency with the tools you're using. Those
can be programming languages/OSes/libraries/other software.

\- You need experience. Having seen different approaches to solving various
problems. Which ones worked. Which didn't. Having tried a few different
approaches, different languages.

\- You need domain knowledge. If you're working in a certain field you need to
know the state of the art. You need to be able to read papers in the field.
You need to be able to apply whatever techniques are required for the domain.

\- You need to be a problem solver.

These are sort of basic table stakes for being a good "programmer".

In most real world settings you need to have some more on top of that:

\- You'll need to be a good communicator. You will need to interact
effectively with many different people, e.g. your boss, a product manager,
junior developers. It's a team effort.

\- You need to understand users/customers. You need to be able to gather
requirements, ask the right questions, and deliver something useful.

\- You need to understand the life-cycle of software. How long will it be in
use? What sort of maintenance work will it need. How will it evolve?

\- You need to have some business understanding. Is what you're doing creating
business value?

\- You need to appreciate the right trade-offs. Sometimes a crappy solution
sooner wins over a perfect solution too late. And sometimes you should wait
and have a perfect solution. That's just one example of a trade-off but our
job is full of them.

\- You need perseverance. Sometimes things take longer than you think. Some
bugs take a lot of work to chase down.

~~~
tomcam
Algorithm knowledge too

~~~
collyw
Rarely, assuming you can read the docs enough to understand what pre-built
library to use.

~~~
douche
And assuming that A) the docs for the libraries do exist, and B) that, if the
docs do exist, they don't look like the output of a million coked-up monkeys,
that was then run through an automatic javadoc generator.

It's just staggering how shitty a lot of documentation is. I can forgive a
one-person github repo for skimping on it, but I get a little irate when I'm
using APIs from Fortune 500s and have to resort to decompiling because their
docs are missing, incomplete, incorrect, or otherwise hot garbage.

~~~
collyw
Switch to Perl or Python if that stuff bother you. I find the libraries there
are generally of a decent quality. JavaScript not so much.

------
tenpoundhammer
I've been programming professionally for the last 6 or so years, I've been in
4 teams across 3 companies. The reason this question generates so many answers
with such great diversity is that the answer really depends on where you work
and what you consider success to be.

At the first company, a good software engineer was a person who could
effectively work inside of the team and get through the requirements for code
review in a timely manner. While working at another job a good programmer was
someone who could figure out the requirements by themselves and have a working
product to show the boss in a timely manner. At my current a good software
developer is someone who has a strong grasp of their language of choice, can
deliver features to a Product Owner, and who can grab a project by the horns
and lead from an architectural or design perspective.

None of these answers are wrong, they are just reflections of the engineering
cultures they are born from.

Based on my experience a good programmer is someone that understands what
success means in the culture they are currently in and can execute on that.
Long term a good programmer is someone that continues to learn popular skills,
products, frameworks, tools and can continue to follow the path that best
suits them, whether that be a startup, large corp, freelance, or
entrepreneurship.

It's all about opening doors for yourself to walk through.

------
foo101
The current state of software development has been bothering me. Having spent
several years in the software industry, I don't find the motivation to write
good code, or design elegant fixes for bugs. I have worked in large MNCs as
well as small companies and I see the same trend every where: The management
does not care about code quality or elegance. They just want to ship things
ASAP. As a result, even if a few developers care about code quality and
elegance, majority of the developers don't. They just want to put together a
working software, no matter how it is achieved, and be done with their job.

Now, even if the minority of developers have coded a few modules that look
absolutely elegant and neat, it interacts with the majority of the software
that is complex, ugly and sometimes bloated. On top of that, in many teams,
developers often touch each others' code and modules to make bug fixes,
enhancements, etc. which means all code (whether currently elegant or not)
tends towards ugly.

How, under these circumstances, do you maintain your motivation to write good,
clean and elegant code after having worked about 10 years in the software
industry?

------
abc_lisper
> I divide and conquer and get things done.

I had the same insight after many years like the author - that every problem
you do can be broken down into smaller problems, which can be worked
independently and tested independently. Why it wasn't obvious to me early-on I
have no idea. I guess I never developed the intuition to see the efficiency of
the method. Did anyone else among you had the same experience?

~~~
bpchaps
I definitely had that same experience. I've been writing code like that for
about 15 years now and it's only started changing over the past two years or
so.

I think it stems from a few reasons - 1\. I have a tendency to fix small
problems that only need a one-time fix. So, lots of code, but disposable and
messy. 2\. HS programming classes lacked a lot of the meta stuffs, like
refactoring, working in groups, etc. 3\. Most of my coding years have been
spent in a terminal where a combination of awk, sed, grep, xargs, etc works
perfectly fine. A non-trivial number of problems can be solved that way, but
it hits a wall pretty quickly.

For the past few months, I've been writing a lot of Clojure and have found
that it fits my mental model significantly better than Python, C, etc. What's
interesting is that all other languages I code in have dramatically improved
ever since Clojure "clicked". Hell, even my bash-fu has become cleaner,
terser, faster and more bug free. Funny how that works..

~~~
abc_lisper
Hey, I'm currently using Clojure too and I feel the same way!

I think the reason it feels more natural is its emphasis on process instead of
things. You think of computation as series of transformations, and that makes
easy to establish causal relationships among events and thus help reason
better about the system. (I think Steve Yegge first complained about Java,
that it is a land of nouns)

I think the failing of OOP for me is that I never got what an object is! To
me, an object always felt like a weird plane in a n-dimensional axes(because
an object contains other objects), and it was hard to reason about that. For
example, my first (atleast in my latent consciousness) reaction about Abstract
classes was, what is it abstract about? If it is abstract about a bunch of
things, that are only related because of the flow of code, I guess I wasn't
smart enough to crack that effectively.

------
MollyR
I'm training my nephew, he's living with me while going to college in the
philadelphia. He's been getting really frustrated hearing platitudes like this
from his professors.

I've basically been mentoring him and having him read
[https://github.com/braydie/HowToBeAProgrammer](https://github.com/braydie/HowToBeAProgrammer)
, Comp Science with Python, and a couple books on linux and C to help with
some lower level stuff.

He's been struggling a lot with C and Linux concepts. I've been there to help,
and now I have strong opinion C and Linux would make a lot of programmers have
a better understanding of their programs and computers.

~~~
keyboardhitter
I agree that it would help with a better understanding. I can't help but
wonder why aspiring sysadmins and programmers DO NOT have immediate interest
in such things? To me it just 'made sense' and 'clicked' almost immediately.
Maybe I learned from a different angle, but it seems obvious to me to want to
learn these things (C and Linux fundamentals, I mean).

~~~
MollyR
I don't know for sure but. I noticed a lot of his class notes were written for
windows and mac users. Also a lot of it was focused on java and python. I
wonder if C and Linux classes became higher level electives.

------
partycoder
A good programmer is a good problem solver. But it also requires technical
knowledge or ability to acquire it, as well as a good ability to communicate
ideas.

Now, you can solve problems in many ways. They can be solved in the best
interest of the programmer, or in the best interest of the company.

If I have a sales team, and give them a goal to sell $100, and they make a
loan for $100 on behalf of the company and give me $100, that's probably not a
good sales team. Let alone a 10x sales team.

But in software, technical debt (equivalent to buying with a loan) is
something done frequently and some people mistakenly perceive it as being a
good programmer. Usually because they cannot perceive the build-up of accrued
work.

------
lojack
> never be dogmatic about anything

Mostly agree with that with the exception of learning new things. Sometimes it
helps to be dogmatic about things if your goal is to learn something new.

A prime example is TDD. When my goal is to build a working piece of software,
I tend to do TDD for some parts and write tests post facto (or not at all) for
other parts. When learning TDD it helped to force myself to be dogmatic.

Similarly, if you're learning functional programming in a language that isn't
strictly pure, its helpful to be dogmatic about your approach and force
yourself to do things the functional way, while in the real world introducing
limited impurities may be better.

------
Radle
"Write unit tests, they could prove to be invaluable, especially when you
introduce changes to your codebase."

I always read this... What exactly is a unit test? What parts of my software
should be tested? What are some examples of good unit tests and the code that
is tested?

~~~
TeMPOraL
TDD is like object-oriented programming. Nobody can agree how precisely it
should work _in real world_ , but "you'll know it when you'll see it". And
you're 50% likely to embrace it, and 50% likely to decide it's utter crap.

~~~
AnimalMuppet
TDD is more than having unit tests. TDD means that _the first thing you write
are the tests_.

Why does that matter? It means that you're writing a user of your class
_before_ you write the class. That means that the interface of the class gets
designed from the mindset of a user, not an implementor.

More: The interface gets designed by someone who wants to be able to test all
the externally-visible behavior of the class. If you can't test it, you have
to think about re-designing the class interface - often by breaking it up into
smaller classes. I've seen this in practice; the net effect of this is better
class design (plus thorough tests).

That said, I'm considerably stronger of a proponent of _tests_ than I am of
TDD. If you don't like the TDD approach, _still write tests_. Write lots of
them. They'll often save you when you make subtle mistakes in your next set of
changes. (Nothing like fixing a bug, running the tests, and getting informed
of all the implications of your change that you forgot about.)

~~~
TeMPOraL
You see, I'm in that 50% of people who don't particularly like TDD. Even
though I tried it, honest to god, several times.

> _That means that the interface of the class gets designed from the mindset
> of a user, not an implementor._

From my experience, something entirely different happens. The class gets
designed from the mindset of a _third party_ \- the tester. Which is, I
believe, a mindset different from the user. If all you're testing is the
externally-visible behaviour, fine. You're pretty much treating the class like
a library. But if you start injecting stuff into the class to test if some
other dependent services got called properly, etc. - and especially if you
start designing the interface around such testability, then I believe it'll
lead to bad, unreadable code. In particular, I believe adding complexity to
the class for the _sole purpose_ of making it easier to test is a code stink.

TDD taken to the extreme prescribes that you should only ever write dumbest
possible code that makes current tests pass. If you need more complicated
behaviour, you first have to write tests for it. But this gets quickly out of
hand if your project is meant to do anything more complicated than being a
simple CRUD layer, because test complexity rises in lockstep with production
code complexity. I've seen cases when people blindly following the
test->code->refactor cycle created tests that themselves were isomorphic to
the algorithm they were implementing, which makes one ask where did they have
the code that tested if _tests themselves_ are implemented correctly?

So personally, while I like tests (particularly regression tests), I just
can't make myself follow TDD.

~~~
AnimalMuppet
Well, when I did it, I was the tester, and the user, and the coder, and I
switched back and forth frequently - maybe in five minute increments. But I
thought differently when wearing each of those hats. I could see the
difference between ways of thinking in the design of the code.

> But this gets quickly out of hand if your project is meant to do anything
> more complicated than being a simple CRUD layer...

I've done things a _lot_ more complicated than a simple CRUD layer. TDD held
up just fine.

> I've seen cases when people blindly following the test->code->refactor cycle
> created tests that themselves were isomorphic to the algorithm they were
> implementing...

Well, blindly following _any_ methodology is likely to get you in trouble, one
way or another. The problem is blindly following, not that they're following
TDD.

That said, I did TDD, and now I don't. It worked well for me, I loved the kind
of code that came out of it, and I still don't do it any more.

------
halis
It helps to be obsessive. Program in your spare time. Don't be one of these
people that just learns what they need to know to do their job and then stops
learning.

I've been programming professionally for 6 years and I'm learning as much
today as when I started.

~~~
sanderjd
You don't need to be obsessive or program in your spare time to be a good
programmer. It's great to continue to learn indefinitely. It's also great to
leave work at work and build a life rich with a diversity of interest and
activity. You can do both.

------
jnordwick
Simplicity. And when you think you have a good simple plan of attack, simplify
more.

I have rarely had problems from being too simple, and when you do they are
easy to fix, but over complication (over generifying) is always a beast to
fix.

~~~
keyboardhitter
I agree with this, the simplest solution is often the best, and then work on
it until it is elegant. In the visual arts, i use the same line of thought
when i am turning a sketch into a full painting, for comparison.

------
NumberCruncher
I have read a really good book on this subject:

[https://www.oreilly.de/buecher/120174/9783897215672-weniger-...](https://www.oreilly.de/buecher/120174/9783897215672-weniger-
schlecht-programmieren.html)

I think it is only available in German.

------
Clubber
First and foremost, add value to business by solving a business problem. Once
you can do that, follow the DRY and KISS principles.

I've noticed developers who can quote scripture (best practices), but can't
solve a non-trivial problem.

------
slantaclaus
Time, intelligence, resourcefulness, curiosity, stubbornness, ideally being
physically next to programmers more competent than yourself, TIME

Adderall or something like that could also be a plus...

------
doggydogs94
If you have a choice between 500 lines of easy to understand, dumb code or 50
lines of abstract elegance, go with the easy to understand, dumb code.

~~~
tellarin
I call that distinction the difference between an elegant and a clever
solution. Clever being what you mention.

If the programmer can't tell the difference when implementing, then go for a
simpler version, as you suggest.

\- Elegant: Nice, clean, well thought out.

\- Clever: Hackish, terse, too hard to understand for whatever benefit it
brings.

------
awfgylbcxhrey
In my opinion, "be humble" isn't a winning strategy.

Don't be so arrogant that you stop improving or fail to understand mistakes,
but by all means don't be humble. Be proud of who you are and the work you've
done. You work in an industry where 90% of people don't understand what you
do. Chances are your own boss won't understand the actual value you're
providing.

So don't be humble. "There's always someone better than you out there" \--
sure, but that person's not here, right?

~~~
shadowfiend
I think that's crossing the wires of humility and confidence. You can be
confident but humble. Confidence is your ability to come up with solutions and
feel like they are the right solutions, and that they are good or excellent
solutions. Humility is your ability to come up with solutions and realize that
(1) they might not be the _absolute best_ solutions, (2) some solutions that
look like they're better are actually better (and identifying these).

I think it interacts well with the concept of “strong opinions weakly held”.
Have a strong opinion that you've built a great thing, but hold it weakly so
that in the face of clear arguments or evidence that it is in fact not great,
or that another solution is better, you can admit it and adjust. This, to me,
is the right balance of confidence and humility---in programming, as in life.

~~~
awfgylbcxhrey
_You can be confident but humble._

I agree with you in principle, but again, I don't think that's a winning
strategy.

A humble, competent woodworker creates a piece that's beautiful, visually
rich, has a solid, study feel to it, and can be appreciated by _most_. The
software engineer, who checks in a fix on the back-end service that pre-empts
several bugs that had yet to be discovered, goes relatively unappreciated.

So _can_ one be humble and confident? Yes. Will it be understood and
appreciated from the outside? Probably not. Is it a good strategy? Probably
not.

I'd say a person has three options:

1) work for people who are technically competent enough to understand the true
value of your work. In my experience, this is pretty rare out in the real
world.

2) become a salesman and sell yourself at all times. This seems fundamentally
opposed to dominant personality types in software.

3) stop being so humble and be proud of your work. This seems like the most
logical choice to me.

Our industry is rife with imposter syndrome, legends of the 10x engineer,
impressions that everyone else is succeeding flawlessly thanks to polished
blog posts and GitHub portfolios [1], and endless pontificating on things that
often boil down to fashion and code style. I don't think we need anything
telling us to be _more_ humble.

You may be a completely average engineer writing CRUD software for some local
bank. Yeah, maybe that guy blogging about his work at Google would do a better
job than you. But he's not here, and your the best you company has found.
You're valuable and capable. Be proud of what you've accomplished!

[1] - people have written recently about how Facebook causes negative feelings
since you seem to see others only at their best. I think this is normal folks
finding out what tech types have experienced for decades, but nobody has ever
talked about it.

~~~
shadowfiend
While “pride” is often used as the opposite of “humility”---which I think is
maybe what you're getting at here---I don't think pride is always the opposite
of humility. In particular, I think the word can mean many things, and the
meaning you're using isn't the one that's often used as the opposite of
humility.

Fundamentally, I agree that you should be proud of what you've done, even if
10X awesome dude at Google could have done better. For one thing, 10X awesome
dude at Google is surrounded by other Google folks, and by 15+ years of Google
technology. There's being aware that there are better possibilities out there
---indeed, being interested in them and even thirsty to learn more about them
---and there's being embarrassed about what you've done. You can be interested
in the crazy things some people do and want to learn more about those things
while still working at a smaller, more limited scope and being proud of what
you achieve with what you've got. The latter is how you get confidence, the
former is how you get humility.

In short, I think we're probably saying the same thing. When you build a
thing, you should be proud of that thing---unless you deliberately cut corners
for some other tradeoff, in which case you should be cognizant of why you did
it and satisfied with the tradeoffs you made. But that doesn't mean you have
to think there's no better way, nor even that you have to avoid looking into
those better ways. Often, I think these things (thinking there's no better
way, not looking for improvements) are what people mean when they refer to
folks who aren't humble. Certainly, that's what I mean.

------
lightedman
I wish everyone were forced to program everything on a machine with the
resources of a Pentium I-class processor and say 64MB RAM.

Learn to conserve your resources, learn to eschew that which is not needed,
and for crying out loud learn to not write bloated stuff. Even today, most
programs I use on Windows 7 were written back in the days of Windows 95/98 and
they still work faster than any current modern implementation you can find,
and they're smaller.

~~~
rumcajz
Every programmer should be given ZX81 with 1kB of memory to start with.

~~~
lightedman
And after that, the maximum hardware they should be allowed is what I
mentioned. Unless you're crunching massive data sets, you don't need 64-bit
(and most programs don't, excepting games and of course databases!)

