Hacker News Reader

Hacker News

Comment by Crazyontap | Hacker News Reader

Full thread

Crazyontap

My comment is a little tongue in cheek but Here is "How I became a more productive by becoming a worse programmer"

- I stopped worrying about best practices and just do it.

- I hardly refactor my code unless I'm using the same thing for the fifth time. I just copy-paste it instead.

- I never think about optimizing code until I really really need to.

- I write what gets the shit done quickly. I don't care if writing a Class would have been better than a function.

- I love old boring technologies and believe you can still make amazing websites with just PHP and jQuery.

- I don't come up with clever one-liners anymore. I write a 10 line for loop which I could easily replace with a clever one-line code golf.

- Instead of writing my own code, I usually search Stackoverflow first to see if I can do some copy-paste it instead.

View on HN

Not to be rude or anything but if you continue down this road productivity might be the only thing going for you and you'll soon realise you are the only one who can work with your code.

Substitute software engineering with any other engineering descipline with "I stopped worrying about best practices" and you will be able to see what's wrong with your approach. But then again, if it's php, your domain doesn't require too much care.

Exactly. I had coworkers like this, and their code was impossible to understand. To make a simple change to it, it would require days of refactoring just to know you weren't going to introduce a bug.

It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write.

How old is the software and what's the change that needed. If the software is past it's ROI and changes are happening due to scope creep then days of refactoring isn't refactoring it's just days of dev work against new requirements. It's just happening on an old product.

Management may be willing to spend that time and not be unhappy with what you perceive as time wasted because they have seen greater than expected ROI on the product already so it's not a loss to them.

I've ran into these problems with software that wasn't even released yet. Some of these practices will likely bite you in the ass in months or even weeks, not years.

They generally get the next person to work in the code without understanding what was going through your head: and 90% of the time, that’s you, three days from now.

"It's not being more productive, it just seems that you're getting things done faster because you're taking out a loan on the quality of your software (i.e. technical debt) with every line you write." This. When someone does this in a hurry or because they didn't know better, it's understandable. But when someone thinks that this style of working is superior, that's a huge problem.

Paying down tech debt is like brushing your teeth, if you don't do it regularly, you'll end up with more pain and a higher bill at the end.

Although I agree in general, a 10 line for loop is usually more readable than a clever one liner.

Sure but 10 lines is often more places for bugs to hide.

If it is decomposed one-liner -- then likely not often

What about a dumb one liner? Or, you know, using HOFs.

I agree with your point but I find the dig at programming in PHP devaluating it.

I apologise for that. Actually that wasn't my intention. I meant to type "May be it doesn't require too much care" but I was typing on a mobile and I missed it.

I do not look down on any programming language. What I meant there was that php is often used for Web applications. Not server side performant critical or security critical components or systems programming. There's also a practical reality that some kind of coding doesn't require too much regulation on how we need to write code. I realised that bit came out wrong but I couldn't edit it.

I like Joe Armstrongs 7 deadly sins.

1. Code you wrote you cannot understand a week later - no comments.

2. Code with no specifications.

3. Code that is shipped as soon as it runs and before it's beautiful.

4. Code with added features.

5. Code that is very very very fast and very obscure.

6. Code that is not beautiful.

7. Code you wrote without understanding the problem

Everything your doing is perfectly ok as long as the productivity gains are there. The lack of a generic function where something occurs 5 times has potential future risk only because it makes refactoring harder. But if you don't deliver a product because your lost building generic things then you don't get to have legacy and support problems.

In fact I'd say that until someone is able to quantify the revenue lost and be able to directly tie it against the choices you are making then stay the course.

+1. Add:

- Use long expressive variable/function/class names that tell me exactly what this variable/function/class does

I have to constantly fight the urge to have code fit in the littlest amount of space possible.

Variable names sound be succinct . They don't need to be short, but they also shouldn't be essays. I had one coworker who would essentially write everything the function did. Variable names would be 100+ chars. It was impossible. Variable names should be as long as needed , but no longer.

I use variable, function and class names as a rough guide on whether I need to refactor. If I name it accurately and the name gets too long, its probably doing too much.

> I stopped worrying about best practices and just do it.

I do this to some degree - I pick and choose my best practises because, quite frankly, some "best practices" are actually bad IMHO ("anti-patterns").

This is sometimes very context-dependent, but I'm now more sceptical of adopting a common practise that I personally haven't seen the benefit of.

e.g. YAGNI:

Maybe the problem isn't YAGNI, but that you keep building useless shit. Rather than assume things aren't needed in general, maybe work on why your predictions on what YGN are so poor.

Sometimes, the stuff I predict I'll need Are needed after all, and I was glad I started early. Projects can live and die on the how perceptive wrt future changes its devs are; this is just a developed skill, no maxims needed.

> I never think about optimizing code until I really really need to.

The point of 'really really need to' has long been passed and you didn't notice it.

(Unless you use an entry-level $200 notebook for development, which you probably don't.)

In other words, please please eat your own dogfood. Your users aren't browsing your 'amazing websites' with a development notebook.

Your code is probably a nightmare for the next person to maintain. Have you ever worked on the same project with your own code for more than a year or two?

Though I'll agree with you on two points - boring old technologies and searching Stack Overflow.

Optimizing code is something you don't need to worry about a lot of the time. Having understandable code is a lot more important in my opinion, but you don't seem to care about that.

In saying that there are plenty of jobs where code doesn't need to be maintained. Most bioinformatics research just need to produce a graph or heatmap and gets used once, so maintainability isn't so important.

5 times is perhaps a bit high, but many best practices advocate for not abstracting until you re-use the code >3 times, since you may end up adding too many conditionals in to handle all the slight variations.

Also - as long as your code is written to be easily readable and refactorable, refactoring can be done when needed. It’s dense complex code that’s too tightly coupled that’s the long-term burden.

It’s often about how the code fits together rather than the individual syntax itself.

The so-called best practices are wrong sometimes. Or maybe they just talk about generic cases. In which case they often are wrong as well. Having the same code twice can already be highly problematic if it is a longer stretch of code. It is virtually guaranteed that the two places start diverging and then the question is why. Is it because it actually needs to be different? Is it because a bug was fixed in one place that should have been fixed in the other as well but was forgotten?

I like your honesty and the nonlinear path you took. I find my road is similar.

I must agree. If one takes a set of low level practices (like those defined for Spartan programming or something your company likes) and copy pastes that kind of code, it's going to be easy and readable and refactorable.

I have not used OOP or programming patterns or whatever for years and no one got hurt. In various code bases I never used inheritance (abstract classes) or method/dependency injection or whatever someone might ask me in an interview.

The code I copied from elsewhere would just get adapted to the company (Spartan) style and that's it.

Only works if you are writing for yourself and not with a team.

> only

Depends on the team. If it’s a team of code ninnies that hem and haw over the “correct” way to do something while deadlines are missed, this is bad. Worse even than ugly code.

Balance. There has to be balance.

This is fine as long as you don't stop there; the adage goes "Make it work", which is what you're describing, but don't forget "Make it pretty" and optionally "Make it fast".

Be kind on yourself, your teammates and whoever follows in your footsteps down the line and spend some time tidying up after yourself if you're not building throwaway things as personal projects.

Most of that is good. One factor is if you are writing code for yourself to maintain or a team.

If it is for a team, you need to take into account if other people can understand your code. Practices like SOLID and just using the type system well don't make it slower to write code but will help maintenance down the road.

Ironically, even this list is a set of best practices that are sometimes specific to the use case.

>Instead of writing my own code, I usually search Stackoverflow first to see if I can do some copy-paste it instead.

Yet, I find most of the code snippets posted to Stackoverflow to be garbage. I despair if these are being copy and pasted into production stystems :(

“and believe you can still make amazing websites with just PHP and jQuery.”

Found the Magento developer.

congratulations you write horrible software

Depends on the perspective doesn't it? If the software does what it advertises, and gets to market faster than the competition, then by definition it is good software. It's only in our blinkered views that we ignore these considerations.

Software is never write once and done. You may get to the market faster in the first iteration, but the follow up iterations can come to a grinding halt because modifying, extending and patching the existing code now becomes an enormous challenge.

But do they ship, while the competitors are fretting over variable names?

Reply on news.ycombinator.com