6 ms·
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 an
by Crazyontap 7y ago
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.
- scabarott 7y ago+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.
- chrismcb 7y agoVariable 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.
- mattchamb 7y agoI 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.
- quickthrower2 7y agoMost 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.
- kovac 7y agoNot 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.
- readme 7y agoExactly. 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.
- gonzo41 7y agoHow 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.
- bcrosby95 7y agoI'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.
- fiddlerwoaroof 7y agoThey 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.
- gonzo41 7y agoEverything 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.
- mattwad 7y agoIronically, even this list is a set of best practices that are sometimes specific to the use case.
- eskaytwo 7y ago5 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.
- cjfd 7y agoThe 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?
- PeCaN 7y agocongratulations you write horrible software
- callmeal 7y agoDepends 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.
- mtberatwork 7y agoSoftware 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.
- JustSomeNobody 7y agoBut do they ship, while the competitors are fretting over variable names?
- DantesKite 7y agoI like your honesty and the nonlinear path you took. I find my road is similar.
- arvinsim 7y agoOnly works if you are writing for yourself and not with a team.
- JustSomeNobody 7y ago> 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.
- ddrt 7y ago“and believe you can still make amazing websites with just PHP and jQuery.” Found the Magento developer.
- otabdeveloper2 7y ago> 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.
- Cthulhu_ 7y agoThis 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.
- superpermutat0r 7y agoI 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.
- Chris2048 7y ago> 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.
- LandR 7y ago>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 :(
- collyw 7y agoYour 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.