Knowasiak
1x Programming

1x Programming

Meet this helpful !!
It’s actually okay to be a 1x programmer. Or even a 0.7x programmer.

Programming is a tool, little more

It’s absolutely fine to treat programming like a tool, rather than something that has value in and of itself. If
you’re worried about not being good enough, I assure that skill will
come over time. If you’re making progress, extending yourself and
somehow avoiding burnout – then you’re doing well.

What
do I mean, “like a tool”? Well, programming is a tool in the sense that
most programming is done to achieve something other than programming.

Spending
three hours in front of a screen might enable you to start a business,
to pursue some creative outlet or perhaps to fix some problem in the
world. But, under this mindset, programming has no a value in itself.

If
there was a better tool than programming to achieve your aims, you
would be perfectly entitled to learn that instead. A formal way to
describe this would be to say that programming’s value is purely
instrumental, or its value is derived from the other things that you
produce with it.

That’s not
to say that you’re not entitled to refine your skills and improve your
productivity. However, I want you to know that you’re not a lesser
person because you’re not able to produce 10x of something that’s almost immeasurable, like software. It turns out that some programmers are at least 10x more productive than others, however no one is born as a better programmer.

Here
are some principles that I think hold merit. I haven’t ranked them in
any particular order. I hope that you feel like they’re slightly
provocative. I don’t want this list to seem like it is in any sense
canonical. I’m learning too. So feel free to pick and choose!

Principles of the 1x programmerSoftware is a team sport

Even if you’re coding for yourself, you’re still coding for a team. Your
future self will not have the same cognitive context that you do
currently. Therefore, you should always code in a way that respects the
people who are following you.

One of the best introductions to this type of socially minded programming is called Building Software Together (freely licensed under CC-BY-NC 4.0) by Greg Wilson and contributors.

Our aim is to teach you how to be a compassionate programmer:
one who cares as much about the well-being of their colleagues and
users as they do about their own. This focus is not entirely
altruistic—everything you do to help others also helps your future
self—but now that we all know how much harm software can do, we hope
you’ll be interested in some practical idealism.

Learn through mimicry

Find the best software written in
your programming language of choice. Usually, the language’s standard
library is a good place to start. Look for patterns. Try to consider how
you would implement things.

Small children learn by copying others. Why shouldn’t adults?

Being a computer scientist is less useful than you might think

​​Synthesis is essence of
software engineering, whereas abstraction is the essence of computer
science. Your job as a software developer will be to synthesise
something new from composable pieces. What you create should be simple
to understand and extend.

You are unlikely to implement sophisticated data structures and algorithms.

I don’t agree with everything that pg writes, but this struck out.

99.5% of programming consists of gluing together calls to library functions.

The time to fix things is now

Your
team isn’t going to have fewer priorities next week or next month.
There will not be an opportunity to do the wholesale rewrite that the code
base deserves. The only way to improve a code base is incrementally.

I learned this through John Ousterhout’s book, A Philosophy of Software Design.
The overall suggestion that I took away from the book is that if your
team is struggling with a spaghetti code base, its members should be
investing about 10-20% of their total development time cleaning it Up.

You’re paid to build

If you think that you’re employed to write software, then you’ve not thought hard enough.

You’re employed to make money – or save money – for someone. And the way to do that is probably through programming.

The phrase is terrible, but it’s worth repeating anyway. Make sure that you “add value”.

This matters because sometimes – perhaps often – working on the boring
thing that no one wants to work on is really the thing that you should
be doing.

Simplicity really helps

We
all want to write simple software, as hard as that is. Ideally, your
code should be simple enough so that a junior programmer who doesn’t
like you can understand it.

Ironically,
simple code probably has a shorter lifespan than complex code. Complex
and difficult code remains fixed because people are afraid to change it.
Complex code is very hard to test. And without regression tests, we
don’t know if we’ve broken behaviour. So it becomes brittle.

API beats algorithm

Syntax matters. One of the lessons from the success of Kenneth Reith’s requests
package — which completely took over from the standard library’s own
implementation of making web requests — is that the (public) API is more
important than every millisecond that you save from implementing the
perfect algorithm. Users care about convenience. Convenient code is easy
to write, easy to read and easy to maintain. However, it’s also important to
understand what comprises your “Porcelain API” and your “Plumbing API”.

Other people make mistakes

The majority of us are better drivers than average. I’m sure the same is true for programming. Brains are imperfect.

It’s impossible for you to assess your own skill level.

If you want adoption, software is just the start

If
you care about adoption, there’s lots of work to do once the code has
been written. That is, unless you’re Fabrice Bellard, I guess.

This,
to me, is the ultimate reason why being a 1x programmer (even in a
professional setting) can be sufficient. You might be able to contribute
to other areas that someone who is focused purely on the code is not
able (or, more commonly, unwilling) to do. 10x programmers care about
the code. Everything else is secondary.

Users
care about themselves. To them, they need to be the primary priority.
This rift causes a problem when open source maintainers decide that
their users are indeed secondary. But that might be the theme of a
future post.

Please improve this list
What have you learned in the course of your learning journey? Please let me know. I have plenty to learn.

Thanks to Nimo Naamani for helping me fix some typos and grammar issues.

Read More
Share this on knowasiak.com to discuss with people on this topicSign Up on Knowasiak.com now if you’re not registered yet.

About the author: Roxane

Get involved!

Get Connected!
One of the Biggest Social Platform for Entrepreneurs, College Students and all. Come and join our community. Expand your network and get to know new people!

Discussion(s)

No comments yet
Knowasiak We would like to show you notifications so you don't miss chats & status updates.
Dismiss
Allow Notifications