An open letter to less experienced developers | Hacker News Reader

An open letter to less experienced developers

medium.com

33 pointsPaulRobinson7 comments

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

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

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.

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.

It sounds like you should be doing something else besides working on CRUD apps, something on the forefront of technological or scientific advancement. Maybe dip your toes in ML with Tensorflow? There are definitely some problems out there that you can't do in your head.

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.

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.

Reply on news.ycombinator.com