[HN Gopher] Are you a lazy programmer?
___________________________________________________________________
Are you a lazy programmer?
Author : tigroferoce
Score : 112 points
Date : 2021-04-10 15:37 UTC (7 hours ago)
(HTM) web link (www.lazyprogrammer.it)
(TXT) w3m dump (www.lazyprogrammer.it)
| mezi wrote:
| This was quite underwhelming, even for a dumb advertisement with
| spelling errors.
|
| >"A lazy programmer writes a lot of tests, so QA junks do not
| waste their time."
|
| I'm really trying to wrap my head around this sentence, but it
| just doesn't make sense. Also please just don't talk down to QA
| like that.
|
| 0/10, this site actively makes me not want to work there.
| chrisbrandow wrote:
| Talk about misunderstanding the meaning of the word, "lazy"...
|
| ;-)
| breakingcups wrote:
| Apparently a lazy programmer does not spellcheck.
|
| Also, this does not seem lazy to me at all: > A lazy programmer
| writes a lot of tests, so QA junks do not waste their time. > A
| lazy programmer documents their code, so thar [sic] coworkers do
| not waste their time.
| golergka wrote:
| I've been moving a large codebase to use unit and integration
| tests lately, and it's definitely saved me a lot of time
| compared to what I would spend on manual testing.
|
| And also, as a programmer I enjoy the process of writing and
| debugging tests much more than manual testing, so even if it
| wasn't a time saver, it would still make my job more enjoyable.
| yawnxyz wrote:
| I started documenting my code so future me doesn't need to
| spend a lot of time figuring it out...
| nicklecompte wrote:
| > A lazy programmer documents their code, so thar [sic]
| coworkers do not waste their time.
|
| I have been compelled to write detailed documentation
| specifically because I was getting tired of being asked
| questions about it[1]. Though I would say the issue isn't
| really laziness so much as general asociability and a need to
| focus...
|
| [1] It does nothing to stop the flow of questions but it does
| mean I'm more likely to give an answer that's actually correct
| :)
| thrower123 wrote:
| Did anyone ever read the documentation?
|
| Serious question. I've spent a lot of effort writing internal
| and external documentation for various systems over the
| years, and I'm not sure anybody ever read any of it.
| tigroferoce wrote:
| I think that clean code is more useful than documentation.
| However in some cases it's not clear _why_ some code was
| written that way, more than _how_ it was written. In that
| case a couple of lines of documentation helps IMO.
|
| Also, if you write relatively small and short functions and
| you document the goal, the inputs and the result, then the
| code is quite self explanatory.
| nicklecompte wrote:
| It really depends on the domain. I think your comment is
| generally true for "most code," since most code involves
| relatively simple concepts familiar to most programmers,
| and is performing a fairly clear task.
|
| But there are many functions where it is reasonable to
| have even hundreds of words worth of comments:
|
| - anything that heavily uses intrinsics and requires the
| programmer to have a detailed mental model of the CPU in
| order to analyze (e.g. making an ASCII table of the
| register state at each major step of the program).
| Likewise with assembly programming, though obviously
| that's a special case.
|
| - a particularly sophisticated graph-theoretic algorithm,
| for which the "comment" might be essentially a short CS
| paper explaining how the algorithm works, giving its
| time/space complexity, and proving correctness
|
| - the "main function" for simulating a physical or
| financial system, which might required detailed
| descriptions of the equations, parameters, and various
| options
|
| I am working on some compiler stuff and have taken to
| literate programming for basically everything that's not
| a simple utility.
| nicklecompte wrote:
| Yes - often a question would be answered just by pointing
| to the documentation or relevant comments in the code and I
| am sure my coworkers read the docs independently as needed.
| Though especially at my last job the domain logic was
| especially tricky (health research informatics / HIPAA
| stuff / etc) so that might mean documentation was unusually
| valuable in that particular job.
| Kluny wrote:
| No, but you can answer their question by linking to the doc
| or telling them the title of the doc to google it
| themselves.
| Igelau wrote:
| I read it, and I read its absence as well. If there is no
| (insert interface commenting format that your IDE can
| parse), that's a code smell. Too often the preceding devs
| didn't explain themselves because they couldn't.
| Igelau wrote:
| I'm guessing the typos were a trap, considering their proximity
| to "silly and tiring things".
| imafish wrote:
| Agreed.
|
| Would rather say:
|
| A lazy programmer documents their code so they do not have to
| waste time explaining it in person.
|
| A lazy programmer writes thorough automated tests so they do
| not have to waste time on repetitive manual testing.
| yoz-y wrote:
| Do we have the same definition of lazy? A truly lazy
| programmer does neither. If they still have their job it's
| because if stuff blows other people know that it's easier to
| fix by themselves rather than chase the lazy programmer to
| fix their shit.
| fiddlerwoaroof wrote:
| There's an old programming meme about laziness being
| invoked here: http://threevirtues.com/
| yoz-y wrote:
| This virtue should always be accompanied by knowledge of
| this table though: https://xkcd.com/1205/
|
| I know that I am guilty of automating stuff for way too
| long :)
| yarcob wrote:
| A lazy programmer writes a bunch of tests, writes just
| enough code that they pass, then creates a PR and lets
| someone else find all the corner cases they didn't bother
| to think about.
| karmakaze wrote:
| s/lazy/effective/g
| shoto_io wrote:
| Reminds me of a quote by Kurt von Hammerstein-Equord, a German
| general:
|
| _I divide my officers into four classes as follows:
|
| The clever, the industrious, the lazy, and the stupid. Each
| officer always possesses two of these qualities.
|
| Those who are clever and industrious I appoint to the General
| Staff. Use can under certain circumstances be made of those who
| are stupid and lazy.
|
| The man who is clever and lazy qualifies for the highest
| leadership posts. He has the requisite nerves and the mental
| clarity for difficult decisions.
|
| But whoever is stupid and industrious must be got rid of, for he
| is too dangerous._
| CyanDeparture wrote:
| What about the people who are clever and stupid?
| saltyfamiliar wrote:
| They make great comedians.
| dang wrote:
| https://quoteinvestigator.com/2014/02/28/clever-lazy/
| shoto_io wrote:
| Nice!
|
| _> In conclusion, this was a difficult expression to trace
| because it was complex, and it could be articulated in myriad
| ways. Currently, the earliest example located by QI appeared
| in English in 1933 and was credited to Kurt von Hammerstein-
| Equord._
| tigroferoce wrote:
| I read the same statement, attributed to other German generals,
| namely Rommel and Von Moltke I think.
| lenkite wrote:
| How can you be industrious and lazy ?
| dijksterhuis wrote:
| The old urban legend of the sysadmin who wrote scripts to
| send an SMS to his wife depending on whether he still had
| active ssh connections at 6pm comes to mind.
|
| Others might call this _being efficient_ or _work smart, not
| hard_ etc. etc.
|
| To me, it's quintessential laziness at its most glorious.
|
| Edit: knew there was a link somewhere
| https://github.com/NARKOZ/hacker-scripts
| Kluny wrote:
| That's the point, you can't. They are opposite ends of a
| spectrum.
| tartoran wrote:
| A lazy programmer thinks a lot before they write a single line or
| code.
|
| A lazy programmer produces the simplest and most graspable
| solution.
|
| A lazy progammer has the easiest time explaining their solution.
| mjhagen wrote:
| too lazy to reply to this in a meaningful way
| serf wrote:
| if you're going to try to sell me folksy wisdom do me the favor
| of warning me that it's for an advertisement before-hand, please.
|
| I felt cheated after reading that page with as positive an
| outlook as possible -- while disagreeing left and right mentally
| -- only to find out on the last line that it was a self-promotion
| _for a company_.
|
| I can't wait to read 'The Hacker's Manifesto, Brought to you by
| Microsoft'.
|
| What a crummy feeling; and congratulations 'Saasform', I
| associate it with that name.
| ilgattodelvicin wrote:
| In case you are a lazy js dev and you speak italian you could
| even apply here https://www.linkedin.com/jobs/view/2474608042 :)
| quickthrower2 wrote:
| The lazy programmer rejects mainstream society, lives in a tent
| and forages and never has to work again.
| coolgoose wrote:
| Ha, interesting. I actually wrote something that matches the same
| thing a while back. https://alexandrubucur.com/blog/2020/why-
| developers-should-b... (insert Spiderman meme)
| 0x4d464d48 wrote:
| Still somewhat hard working but getting lazier by the day.
|
| I work as hard as I can to be as lazy as I can.
| kstenerud wrote:
| Not by that definition, I'm not.
|
| Look, I get that you're trying to cleverly put in a bunch of
| rules that "make a good programmer", but rules do not the master
| make. A master knows the best practices and rules, knows why they
| apply, and knows where their usefulness ends. Many of the
| properties here range from naive to downright dangerous.
|
| Example:
|
| - "A lazy programmer do not deploy in production, they instruct
| Jenkins to do that. Therefore a lazy programmer is not afraid of
| deploying on Friday afternoon."
|
| Using a tool to deploy does not remove all of the risks of
| deployment. If you deploy on Fridays, you WILL eventually be
| there on Saturday fixing a problem.
|
| - "A lazy programmer is a master of delegation. After they
| delegated a task, they immeditaly forget about it."
|
| Also very bad advice. Forgetting about a delegated task removes
| you from the chain of responsibility. If you're delegating, it's
| on YOU to follow up. Otherwise things get lost in the chaos.
|
| I'm not going to run through all of them. Please just disregard
| this site and take lists of "a good programmer does..." as a red
| flag for the company promoting it. A good engineer is not made
| through lists and rules. If it were that easy, we'd all be good
| engineers.
| gabereiser wrote:
| Upvoted because every counter point presented was on target and
| with solid examples. The article for me read a little tongue in
| cheek but there are some serious errs in reasoning for some of
| these. Just toxic behavior.
| athrowaway3z wrote:
| If i had to take a cynical guess, this was written by someone
| who thought: "Programmers respect laziness ( See Bill Gates
| quote ). So attaching my beliefs to the idea of a 'lazy
| programmer' and putting it on a dedicated domain my virtue
| signaling has a higher effectiveness"
|
| I'm a little sour because apparently "writing a blog" is not
| hip anymore and we need dedicated domain for every brain fart.
| bckr wrote:
| Well, it's a marketing page.
| ipaddr wrote:
| Your countpoints are solid advice for a good programmer.
|
| For a great programmer you are missing that they control the
| environment as well.
|
| If you know who you are delegating to you know what will be
| returned, when and how that is going to affect the next step.
| As a great programmer you are 15 moves ahead. Why would you
| worry about chaos? There is a lack of trust in your plan if
| fear of chaos exists. You are Michael Jordan and can see the
| entire court.
|
| As an average developer I don't trust anything will work even
| if it was just tested.
| mikewarot wrote:
| This is an infuriating mix of great and horrible ideas, in a
| horrible attempt at either humor, or sarcasm, in quantum
| superstition.
| winstonchecksin wrote:
| I agree on many but not all of these points. This list is setting
| some expectations, and what I mean is that some programmers here
| will see this list since it's trending on HN and lose their self
| esteem or try to forcefully change their behavior to meet this
| bar.
|
| > A lazy programmer is super efficient, does in a couple of hours
| what would take a whole day to others, so that they can spend the
| rest of they lingering on the couch feasting on Netflix.
|
| This is a crazy high, unrealistic bar. It's almost comical.
|
| > A lazy programmer startes at the code for hours, trying to
| figure out the way to write as little code as possible.
|
| I may or may not want someone on my team to do this, depending on
| what it is their working on, its significance, etc. but staring
| at your code for hours on anything you work on probably means
| you're not great at making trade offs and haven't considered if
| what you're doing is actually worth trying to over optimize.
|
| > A lazy programmer uses the basic UI template the hosting
| service provides them and then they say it's brutalism.
|
| This is some pretentious gate keeping. Does the lazy programmer
| also hack into government "mainframes" in 10 seconds?
|
| > A lazy programmer do not deploy in production, they instruct
| Jenkins to do that. Therefore a lazy programmer is not afraid of
| deploying on Friday afternoon.
|
| Jenkins isn't a solution to when you deploy. You could have all
| the tooling for effortless deployments but not have enough test
| cases, canaries, etc. And your software failing, especially if
| it's a service, could have a blast radius that now impacts
| several other teams and their on calls on a late Friday. And it
| might not even realistically be in your control to get the
| automation quality to the bar you'd love to have because of
| competing priorities and ROI.
|
| If you're someone young at HN, please take this stuff with a
| grain of salt. This document sets realistic standards of what it
| means to be a lazy programmer (in a good way) the way the
| Kardashians set standards on beauty with their fake photoshopped
| Instagram images.
| 908B64B197 wrote:
| >> A lazy programmer stares at the code for hours, trying to
| figure out the way to write as little code as possible.
|
| It's easy to write a lot of code really fast. Then bolt in on
| an existing application and write as much code doing the
| bolting as you wrote initially.
|
| Reading a lot means getting an understanding of what you are
| about to extend, figuring out the best way of doing it and
| what's already provided by the application.
| mattacular wrote:
| Replace lazy with the word good and I agree with everything in
| this post.
| cloudrkt wrote:
| Deploy on a friday is still a no go for us.
| giantg2 wrote:
| It's often required that we go on a Friday or Saturday to
| minimize potential impact if there's an issue
| yoz-y wrote:
| When I was briefly working in a construction plant.
| Weekends is when non critical or potentially risky
| operations on machinery would be done, as to not block the
| production chain during workdays.
| linkdd wrote:
| When you work on weekends too, a friday is just like any
| other days.
| tigroferoce wrote:
| Some [1] propose to split the week in a different way, so
| that you take a day off on Wed and one on Sun and you work
| on Sat, so Fri becomes like Thu.
|
| [1] https://www.youtube.com/watch?v=ALaTm6VzTBw
| imdsm wrote:
| Or when you have a robust CI process in place
| linkdd wrote:
| I have 100% code coverage in my unit tests + behavioral
| tests (with cucumber).
|
| And yet, problems still happen.
|
| Programming is the art of adding bugs to an empty text
| file.
| wdfx wrote:
| Even an empty file can contain a bug, by virtue of being
| empty.
| enw wrote:
| For any somewhat complex architecture, even with great
| tests and canaries there will be unexpected issues.
| lostcolony wrote:
| I've yet to see the place that had the level of testing,
| and infallability of the CI process, to where I wanted to
| deploy on a Friday. Yeah, it may be a low chance that
| anything will go wrong, and an equally low chance we'll
| be unable to easily rollback, but so few things can't
| wait until Monday that I want to roll those dice.
| Vinnl wrote:
| I know it's mostly just a meme, but I find the idea that laziness
| is a virtue unfortunate; IMHO it's one of the worst vices a
| programmer/team player can have.
|
| Not taking five extra minutes to explain what you did when
| submitting a Pull Request - that's laziness, and forces your team
| mates to spend more time and mental effort on understanding
| what's going on.
|
| Not going back over your diff one last time before submitting it
| for review - that's laziness, and it puts the onus on discovering
| things you forgot on your team mates.
|
| Not going through the effort of making individual changes easy to
| revert - that's laziness, and it forces the future maintainer
| (possibly yourself) to put in extra work at a time when they're
| under stress, e.g. when fixing a critical bug.
|
| I could go on.
| Igelau wrote:
| While do you have a point, there's no virtue that doesn't
| become corrosive when pushed to the extreme. The author is
| clearly advocating a safe and useful subset of lazy behaviors.
| Mostly the kind that avoid tech debt and burnout.
| w0mbat wrote:
| It's "lazy" in the sense that you look for the simplest most
| leveraged way of doing something well, not "lazy" as in
| negligent.
|
| A lazy programmer takes time to search for the things that the
| OS will do "for free". Keeping up with and using, the latest
| developments in OS libraries. This can save you a lot of
| coding, and gives you capabilities that are likely to keep
| working on diverse future hardware.
|
| A lazy programmer will check in the smallest possible fix when
| fixing other's code. The simplest change takes time to isolate,
| but it causes the least disturbance and reduces chance of side-
| effects and new bugs. It also makes the change comprehensible
| to others, which saves time having to explain it.
|
| If you do something right the first time, you don't have to do
| it again, and in order to do that you have to do it simply and
| carefully or you will never get it right.
| intrasight wrote:
| Did anyone look at sassform? Impressions? Alternatives?
| TCS_ wrote:
| Decent ad.
| self_buddliea wrote:
| I was expecting something about lazy initialisation.
| happytoexplain wrote:
| Seems like the author was trying to draw a correlation between
| good practices and "laziness", which is a cute analogy that makes
| sense in many cases, but then they forgot and just started
| listing all good practices.
| jhardy54 wrote:
| > A lazy programmer do not edit long files, they teach regular
| expressions how to edit the file in their place.
|
| A lazy programmer uses a proper parser instead of trying to write
| a parser in regular expressions.
| lhousa wrote:
| An here is the https://1x.engineer/
| 908B64B197 wrote:
| That list also applies to 10xer.
|
| Not all 10x are jerks.
| yoz-y wrote:
| I really like this one. In my opinion, good long term
| successful software is best built by a bunch of this kind of 1x
| engineers.
| Igelau wrote:
| This is the best, though
|
| "Respects and upholds community Codes of Conduct."
|
| kind of feels like a 1.5x criteria. A true 1x hasn't read the
| CoC, and if they have, they didn't memorize it or see the
| e-mail about the latest updates. Though they will course-
| correct if you tell them they've erred.
|
| This is incredibly important:
|
| "Willing to admit when they're wrong, and aren't afraid to say
| "I don't know."
|
| There's incredible power in being able to show your hand with
| an open understanding of how it could be better.
| Stratoscope wrote:
| This is pretty great. I would gladly work with any 1X engineer
| like that.
|
| My favorite bit of humor is:
|
| * Writes code that &emdash; _gasp_ &emdash; has bugs.
|
| The misspelled and non-decoded em dashes started out as an
| actual mistake but are now kept in because of the delicious
| self-reference:
|
| https://github.com/cutenode/1x.engineer/issues/9
| [deleted]
| valyagolev wrote:
| Larry Wall's three virtues of a programmer: laziness, impatience,
| and hubris
| imdsm wrote:
| I feel like this is an attempt to add to this while throwing in
| a plug at the bottom. These are all too specific and
| subjective, and I don't think they're as applicable to all lazy
| programmers as the three virtues are to all (good) programmers.
| Sebb767 wrote:
| > A lazy programmer do not deploy in production, they instruct
| Jenkins to do that. Therefore a lazy programmer is not afraid of
| deploying on Friday afternoon.
|
| Just because Jenkins does the final "cp && restart" does not mean
| that critical bug will not ruin your weekend. The tests mentioned
| before help, but the unexpected is, per definition, unexpected.
|
| In fact, when the house is burning, I found CI deploys to be
| quite a slowdown. But this might just be me.
| gomseb wrote:
| Well, I guess the point here is to rollback to the previous
| version and find and fix the bug on Monday.
| denimnerd42 wrote:
| I'm curious how many companies have a working rollback. I
| think the majority probably have to keep patching until they
| get it right or get it stable.
| lunfard00 wrote:
| maybe because by definition you lose data on rollbacks? You
| can re-run all events/messages (if your company
| architecture supports it) but that gets more complicated,
| usually patching is easier and faster. Also, downtime.
| Sebb767 wrote:
| Sometimes, yes. But the bug might not immediately be obvious
| (for example a memory leak) or cause data corruption, in
| which case you need to get a backup - and you probably don't
| use a backup without manual approval.
|
| A good infrastructure will help you at every point, but it
| will still take time.
| tigroferoce wrote:
| OP here: I agree on some level. I have perfected my vim skills
| by actually modifying the production php source code in my
| youth. However as things get more and more complex, it helps to
| script them down so that you don't have to remember a set of
| commands in a given order. I see the deploy script in this case
| as a "documentation for lazy" :-).
| Sebb767 wrote:
| Fair enough. Our CI does build+deploy and we're on a bit of a
| budget, so the process tends to be `git push`, wait 5-10 min
| for the pipeline to complete, check if it worked, repeat
| otherwise. But that's really something to optimize in our
| infrastructure; in an ideal case, I'm on your side :)
| _the_inflator wrote:
| Apple won't help you during weekends. Our experience. There are
| dependencies, you at first don't think of.
| milesvp wrote:
| Yes. I say deploy in friday, but you better call it out
| explicitely. We'd call it cowboy friday anytime someone
| suggested deploying on friday. That person immediately
| volunteered to be on call. And if anything went south, they
| lost social capital and had to eat crow (mostly playfully, more
| seriously if it became a pattern). If enough people agreed the
| risk was worth the reward, and at least one QA was willing to
| vouch for the push, the yeah, push as long as there's enough
| time to rollback before people leave for the day.
|
| Mostly, it was easier to not push on friday.
| yoz-y wrote:
| Deploying often means a lot more than just "changing some
| binary somewhere in prod" too.
| hyko wrote:
| Yeah, not deploying on a Friday has nothing to do with a lack
| of CI; it's related to the human culture of having a weekend,
| which reduces an organisation's ability to handle the
| unforeseen consequences of pushing to production.
|
| "So just roll back" I hear you say, to which I respond: "it
| ain't always that easy". You can't always just turn the reactor
| off once the meltdown is in progress.
| WrtCdEvrydy wrote:
| We've had this issue many times with dependency management.
|
| CI will rebuild after you revert everything and still fail to
| deploy if you pushed a versioned library from your broken
| code.
|
| Go into your environment and manually roll back to a working
| image... and learn a powerful lesson.
| vergessenmir wrote:
| I'm not sure what you're saying here. I can see this being
| a problem when you have cross-team dependencies and your
| roll-back requires coordination.
|
| Even then it's manageable if your production deployments
| are version pinned, it only becomes a problem if schemas in
| your database or messaging have had non compatible changes
| and data has been written (i.e you have binary and data
| dependencies in a release)
|
| All this being said with the assumption that the CI/CD
| pipeline has been designed to best practices.
| runarberg wrote:
| Why is a developer deploying to production in the first place?
| To minimize the work for everyone the code should have gone
| through QA before it was passed to ops. Ops should be confident
| that QA did their job sufficiently ("A lazy programmer knows
| how to delegate") and shouldn't be afraid to start the deploy
| job whenever.
| temporama1 wrote:
| Dude, I'm so jealous that you haven't even heard of DevOps. I
| don't know where you must work but please give me a job.
| Silhouette wrote:
| The trouble seems to be that "DevOps" is the new "Agile".
| How often is it just an excuse to dump non-development
| responsibilities on the dev team, and to ignore boring but
| time-proven processes and tools that specialists might have
| preferred if you'd hired them for those responsibilities
| instead?
| jghn wrote:
| Why are there separate QA and Ops teams?
| mxz3000 wrote:
| Not all companies/teams have dedicated QA and Ops teams.
|
| In the (very large) company I work at, the engineers are
| responsible for writing the code, testing it, and supporting
| it once it's live. That includes being Oncall and being paged
| if something goes wrong.
| void_mint wrote:
| > I found CI deploys to be quite a slowdown. But this might
| just be me.
|
| It depends how you think about it I think. Meaning, it'll feel
| like quite a slowdown but exists to help mitigate errors made
| by humans experiencing varying degrees of panic while their
| house is burning. In my opinion CI deploys are meant to provide
| consistency, not speed (although people generally experience
| speed ups in their deployment process when there are no longer
| "works on my machine" type issues that pop up each deploy
| causing slowdowns in new and exciting ways).
|
| But I also think that programmers flaunt "Friday afternoon
| deploys" too much in either direction. It shouldn't be the end
| of the world but it also is just an unnecessary risk if you can
| help it.
___________________________________________________________________
(page generated 2021-04-10 23:02 UTC)