
An open letter to less experienced developers - PaulRobinson
https://medium.com/@p7r/an-open-letter-to-less-experienced-developers-c33c16ea5e88
======
kilburn
As I grow older, I've found out that I value tools, processes and
organization/conventions more than the code itself. These days it is very
strange for me to look at some piece of code and think "that's amazing".

Part of that is because I keep finding out that the best code is as simple and
"to the point" as possible. Great tools (I'm counting stuff like good type
systems, good meta-programming, etc. in this category) combined with good
architecture/conventions are the real enablers of this kind of code. Once the
former is worked out (which is the really hard part), the latter should just
come naturally given a sensible coder.

As a reuslt, I'm excited about Rust and its "zero-overhead" abstractions. I'm
excited about the Elm architecture, and how it permeated/influenced the
javascript ecosystem (react/vue/whatever). I'm excited (and amazed!) about the
RDBM's we have available (sqlite, mysql, postgres), and the awesome cache/in-
memory ones (redis), and the strongly consistent distributed systems
(etcd/zookeper/etc.), and the web servers (apache, nginx), and the
"application servers" (jetty, uwsgi, php-fpm), and the load balancers
(haproxy), and the heaps of testing tools we have, and I could go on and on...

Almost none of these things existed when I started coding. Databases got
corrupted frequently, client/server programs were almost mythical monsters,
etc.. These were the days when clever code was king (to pack stuff tighter in
memory, to shave off some computation through clever operations, etc.).
Nowadays these hacks are hardly ever necessary anymore, and I couldn't miss
them less.

If you want to see me excited, explain to me how your system works and why it
won't break. This is my takeaway, not your actual code...

------
JeanMarcS
(My 2 cents, I work alone doing mostly professional web apps)

I’ve been coding for around 35 years, and I’m bored. I really am.

The point of developing software (at least in my vision) is to solve problems.
But growing old, I like to find solutions « in my head » (or on paper or white
board). And once I found the solution, I lost 100% of my interest in the
problem. And it’s precisely the moment I have to start coding the solution !

So I try different frameworks or different languages to keep the interest on
coding.

It’s a bit sad I know, but I like learning new stuff or languages so that’s
why I keep going on (and mostly enjoying my job).

~~~
BatFastard
You must be godly. I have a couple of problems I have been thinking about for
years that I could use some help with! But my problems in are the real time
rendering realm.

For me personally I have found that when I find initial solutions to problems,
they are usually just a shadow of the actual problem. The true complexity is
not revealed until I start stress testing it, or making it interact with other
systems, trying to expand it to handle more functionality.

Maybe this can be attributed to the fact that my first step is to just make
things work. And it not until I make them work do I really see the patterns.
Then I usually manage to remove half the code as the patterns and abstractions
resolve themselves.

So for me, coding is essential to truly solving the problems.

~~~
JeanMarcS
I might have mistranslated what I usually work on. I essentially do web apps
for professionals. Intranet is a better word ? Usually CRUD apps with no need
to top of the art designs, just working and adapted to what the client wants.

The most interesting part is sort out the best solution to translate a need
they often have difficulties to explain, as it generally is concept they use
on a daily base and is adapted to the way they work for years (in companies
and projects as diverse as, for example, CRM for multiple AC companies
regrouped in a joint society, gas truck following, with deliveries validated
on tablet, backoffice for an editor for managing authors, stock, and stuff
like that, etc...).

Once I figure it out, menus, shortcuts, the different screens, etc, and
validate with the client, 80% of the job is done.

And then the coding part starts. I don’t say it’s useless and sometimes you’re
right you bump on some problem you didn’t thought of in the beginning.

But most of the time, it’s boring, for me.

As I said, I work alone and most often for small companies, so there is rarely
a lot of people using the systems at the same time. It might simplify it a lot
for me.

------
amriksohata
Spot on, I see many wide eyed junior developers thinking just becse they can
code they can be the next startup enterprenuer with their side project and
show what they can do at their current job. With a bit of experience they soon
realise just because you can code doesn't mean it's good code nor does it mean
it will satisfy the user requirements. Luckily most juniors I have dealt with
respect their seniors and take advice, there are a few who quite frankly
haven't got a clue but make out they know what they are doing.

------
bradknowles
With respect to the OP, code != blueprints. IMO, code == bricks.

But bricks are just one piece of the puzzle of building a house, just as much
as the blueprints are just one piece of that same puzzle. I just disagree
which piece they are.

Other than that, this seems to be a reasonable response on the subject from an
experienced developer to someone who hasn’t been in the business as long.

