Are you a lazy programmer?(lazyprogrammer.it)
lazyprogrammer.it
Are you a lazy programmer?
https://www.lazyprogrammer.it/
95 comments
An here is the https://1x.engineer/
Isn't 1x supposed to be the average software engineer? If yes, then this doesn't align very much with my experience :-(
Or is it supposed to be that many people are less-than-one-x and aspire to be 1x?
Or is it supposed to be that many people are less-than-one-x and aspire to be 1x?
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.
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
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
That list also applies to 10xer.
Not all 10x are jerks.
Not all 10x are jerks.
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.
"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.
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.
>"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.
Still somewhat hard working but getting lazier by the day.
I work as hard as I can to be as lazy as I can.
I work as hard as I can to be as lazy as I can.
> 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.
A lazy programmer uses a proper parser instead of trying to write a parser in regular expressions.
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.
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.
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.
A lazy programmer produces the simplest and most graspable solution.
A lazy progammer has the easiest time explaining their solution.
Yes, of course, I started my career with Perl.
http://threevirtues.com/
http://threevirtues.com/
This is an infuriating mix of great and horrible ideas, in a horrible attempt at either humor, or sarcasm, in quantum superstition.
The lazy programmer rejects mainstream society, lives in a tent and forages and never has to work again.
Did anyone look at sassform? Impressions? Alternatives?
I was expecting something about lazy initialisation.
s/lazy/effective/g
Decent ad.
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.
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.
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.
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.
Yeah I know that that's the origin of the meme (I mean, it's literally in the post), bit when it becomes a quip it still rubs me the wrong way when it's actually true, bit not in the good way.
I guess basically, I'd just like to remove the positive connotations with the term, and instead just focus on the actual virtue: working efficiently.
Of course, it's not a major issue. It's just semantics, and I'm not that much of a 'language matters' type of person.
I guess basically, I'd just like to remove the positive connotations with the term, and instead just focus on the actual virtue: working efficiently.
Of course, it's not a major issue. It's just semantics, and I'm not that much of a 'language matters' type of person.
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.
Replace lazy with the word good and I agree with everything in this post.
Deploy on a friday is still a no go for us.
When you work on weekends too, a friday is just like any other days.
Or when you have a robust CI process in place
For any somewhat complex architecture, even with great tests and canaries there will be unexpected issues.
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.
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
[1] https://www.youtube.com/watch?v=ALaTm6VzTBw
It's often required that we go on a Friday or Saturday to minimize potential impact if there's an issue
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.
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.
Larry Wall's three virtues of a programmer: laziness, impatience, and hubris
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.
> 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.
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.
Well, I guess the point here is to rollback to the previous version and find and fix the bug on Monday.
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.
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.
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.
A good infrastructure will help you at every point, but it will still take time.
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" :-).
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 :)
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.
“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.
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.
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.
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.
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.
Deploying often means a lot more than just “changing some binary somewhere in prod” too.
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.
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.
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.
For a small company with a fairly stable feature release schedule, that is fine. But in a large setting where expectations for new features is high, that seems like a scam. That is it looks like they are trying to get the developer to work double (or triple) shifts but only pay for one.
Why are there separate QA and Ops teams?
Ops usually understand infrastructure, and QA usually not so much. The overall mindset is a little bit different, i.e. QA tries hard to break it, and Ops tries hard to keep it running. And the required skills might also be different (distinct sets of tools, techniques, certifications, etc.)
But I can see that it might be useful to have it all together... (DevOps, QAOps)
But I can see that it might be useful to have it all together... (DevOps, QAOps)
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.
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?
Apple won’t help you during weekends. Our experience. There are dependencies, you at first don’t think of.
> 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.
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.
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.
Mostly, it was easier to not push on friday.
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.
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.
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.
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.
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.
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.
There’s an old programming meme about laziness being invoked here: http://threevirtues.com/
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 :)
I know that I am guilty of automating stuff for way too long :)
> 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 :)
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
No, but you can answer their question by linking to the doc or telling them the title of the doc to google it themselves.
I started documenting my code so future me doesn't need to spend a lot of time figuring it out...
I'm guessing the typos were a trap, considering their proximity to "silly and tiring things".
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.
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.
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.
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.
I read the same statement, attributed to other German generals, namely Rommel and Von Moltke I think.
What about the people who are clever and stupid?
They make great comedians.
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.
> 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.
How can you be industrious and lazy ?
I believe they were intended to be two separate axes: stupid<->clever and lazy<->industrious. This lends itself to the four quadrants referenced in the quote: clever-industrious, stupid-lazy, clever-lazy, and the infamous stupid-industrious
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
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
That's the point, you can't. They are opposite ends of a spectrum.
too lazy to reply to this in a meaningful way
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.
> 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.
>> 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.
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.
[deleted]
Talk about misunderstanding the meaning of the word, “lazy”…
;-)
;-)
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)
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.
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.
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.
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.
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.
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.
I'm a little sour because apparently "writing a blog" is not hip anymore and we need dedicated domain for every brain fart.
Well, it's a marketing page.