Live data from Hacker News

Programming: Doing it more vs. doing it better

kevinmartinjose.com

171–180 of 223 posts

Re: Programming: Doing it more vs. doing it better

#171

Earlier quoted context omitted.

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…

Programming is no different than any other discipline. You aren't going to be an expert in anything in only 3 years. Expert physician? Wont even be out of residency yet. Expert car mechanic? No way. Expert troll on hacker news? Maybe.

Expert car mechanic doesn't take 3 yrs. I went from knowing nothing about cars to building my first race car in 2 years in my late teen years and that's without the wealth of knowledge I can find online today. ... and not just jamming a bigger v8 engine, but slamming a turbo on a 4 banger and not blowing up the engine and shaving almost 3 seconds off the stock 1/4 mile times, with limited budget too.

Something I see with most IT folks is that they think they are so special and feel very threatened when other's can learn what they can and faster too. Being an expert in 3 years is possible in most fields, all you need is dedication and deliberate practice.

We are not special, let's get over it. The only crap getting in the way of youngster's today is filtering out the noise since there's too much crap. But once they sort it out, they will move 10x faster than most of us old timers ever did.

Re: Programming: Doing it more vs. doing it better

#172
The point as applies to individuals extends to projects also:

> Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.

> [...] plan to throw one away; you will, anyhow.

Fred Brooks, The Mythical Man-Month (1975)

Re: Programming: Doing it more vs. doing it better

#173
post #8

Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…

While 3 years isn't much from a whole career perspective, I do believe those may be the three most important years, where you learn the most etc; I'm at about 10 years now, and don't feel like my level has significantly improved since then. I mean sure, I'm more experienced now and know more languages etc etc, but it's not like I'm 10x more productive or smart or better than I was 10 years ago.

Is "10x more productive" even the right way to assess ourselves? I may be writing 1.5 times as much code as I was 2 years ago, but that code per line is much more sophisticated and gets a lot more work done, as I've learned more and more libraries and learned more tips/tricks/shortcuts.

Re: Programming: Doing it more vs. doing it better

#174
post #13

Earlier quoted context omitted.

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…

Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful. Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?

No, they didn't do the modern day ceremonies around programming such as TDD. What they did was code a lot. Code a lot of different things, knew where to draw the line and "finish" up their projects. Maybe out of their many projects, they really took one or two all the way and polished, but most were fast, done and the lessons learned. ... They also stayed deep in the language and didn't rely much on frameworks & libraries.

Here's a sample of things you can do to vary your programming knowledge fast.

Learn multiple languages C, asm, forth, lisp, prolog, any OOP

Code a card game, blackjack, cribbage, poker Code a board game, checkers Code a puzzle game, tetris Code an adventure game (text) Code your own text editor Code your own interpreter (BASIC or your own language) Code a network server & client (not REST, socket programming & threads) Code a basic CRUD app

They are deeply curious about a lot of things and soak up as much as they can, that's all I can say.

Re: Programming: Doing it more vs. doing it better

#175

People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…

I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time…

> I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code

Because people who write "beautiful code" don't often achieve anything that can be seen. Successful companies are based on quickly written code that delivers.

Re: Programming: Doing it more vs. doing it better

#176
post #28
post #7

I use one rule: If it's easy to remove, then it's fine. Because only then, i don't fear refactoring later. So i'll get my goal: Easy refactoring for fun and profit. Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

Indeed. I love it when the amount of money I make is tied to the quality of my code somehow. Easy to modify, easy to repurpose, easy to replace. These often make it possible to serve customers better -> more $$$ It's why I can't really take a regular job. There is no relationship between the quality of my work and what I get paid.

What nonregular job do you do? What kind of code do you deal with, for what kinds of customers? If you're a freelancer or consultant, how often do you end up revisiting code that you write a year or more later?

Re: Programming: Doing it more vs. doing it better

#177

Earlier quoted context omitted.

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment. I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not c…

I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on. How I take the article, and what I think most in this entire comment thread agree with, are the following principles: [1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base i…

What I'm missing in this discussion is that, from my personal experience, people who are very result-oriented hardly ever write correct code. They tend to leave a trail of subtle, hard to find bugs (because foreseeing edge cases is one of hardest parts of programming and doesn't happen naturally while thinking about the happy-path) and poorly designed persistence structures (refactoring code is easy, but refactoring data is painful-to-impossible - you just can't retrospectively collect what you forgot to collect initially).

Of course both extremes are bad. I lean towards the perfectionist camp, so I actively seek to work with someone result-oriented. I've found this teaming to bring great results, where both my partner and myself end up happy with the outcome and fulfilled in ways neither of us would by ourselves (for me because I produce more givem the same time, and for them because they feel much more confident in the resulting programs - corroborated later by the much lower number of bugs found in them).

I know this is the case because I've been told many times by many different people (and most of them actively seek to work with me again afterwards if the opportunity arises).

Re: Programming: Doing it more vs. doing it better

#178
post #5

>> The best writers write much more slowly than everyone else, and the better they are, the slower they write. By that metric George R.R. Martin is on track to be the greatest writer of all the time :)

No. I am (not having ever published a single book yet).

Re: Programming: Doing it more vs. doing it better

#179

People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan what to implement, do it, then improve it…

> Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. Generally done by people who don't think through the requirements or know why they're doing what they're doing. "I just copied pasted the example and hacked it until it did what i wanted. I'm still not sure why it works lol" Completely fucking over the next person who has to work that code.

It's the American way! Leave a steaming pile of shit behind and laugh at the next idiot for stepping in it.

Re: Programming: Doing it more vs. doing it better

#180
As one of the million people who tried to read Ulysses and failed, I'm not sure I'd hold up Joyce as the example of what programmers should aspire to. There's plenty of popular and even good creative works which were written quickly or even under external time pressure.
Post reply on HN