Live data from Hacker News

Be nice to programmers

edu.mkrecny.com

61–70 of 178 posts

Re: Be nice to programmers

#61
What we have done and what happens to us all accumulates inside ourselves and becomes the basis of our future consciousness and state of mind. Peoples' minds and consciousnesses are comprised of energy. If we use the example of a lightbulb, the consciousness is most akin to an electrical wave produced by the generator and the mind is most analogous to the light radiated by the bulb.

If we work in such a way that produces high entropy codebases, hides problems instead of illuminating them, or produce (or have to work with) highly inter-braided (complicated) architecture with no way or occasion in which to improve matters, then it's easier for people to be caught by grudge at their employer, clients, or circumstance. People can be influenced by these bad circumstances to abandon themselves, and in doing so, their resultant ignorant behavior will make their mind mind become dark. This is a most dangerous circumstance for a human being to live in, so the task of the modern programmer is to find out what they have worth living for, to find a good self, and to protect themselves from wrong relationships and from destroying themselves (through loss of simplicity in one's life) such that they can effect their benefit for themselves and the world. Without individual awakening then it doesn't matter what profession they hold, they still can't guide their life properly. So the most important teaching for programmers to save their way of life is that they have to understand properly what life is, how great a teaching it is for us, and just how precious is the opportunity that we have been given through our lives as human beings.

Re: Be nice to programmers

#62
post #45

Earlier quoted context omitted.

> Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough. I'm sorry, but that statement is untrue; there is no generalization for the term "bug". They can be as simple as "your borders on this web page are misaligned" to a subtle memory leak that can only be reproduced on a small fraction of users' systems. Or maybe the bug is a fundamental design flaw th…

Now how often do you run into these subtle memory leaks? How often do you run into fundamental design flaws? Once, twice a year? If it happens so rarely, which for most developers I believe it does, why would you allow it to get you so jaded? Why would it be apart of your daily concerns or something you felt you needed to prepare for?

This depends heavily on the legacy of the codebase you are working with, I imagine. I'm thankful that I (nearly?) never run into serious design flaws, because the people that built this code before me did a really good job. I could easily imagine a worst-case scenario where the code you're maintaining was written by a stream of interns, implementing requirements written by committee, over the space of a dozen years. Fundamental design flaws might be so ingrained, and the codebase so large, that you could not easily refactor it into something nicer.

Re: Be nice to programmers

#63
For me, this cycle is a different one:

(Step 0 is possibly 'get a bug report')

1. Write a test

2. Watch the test fail

3. Write code

4. Watch the test pass (if fail, goto 3)

5. Make the code pretty

6. Watch the test pass

7. Repeat

Instead of negatives, you're looking for positives. At the end you're rewarded with nicer code than you started with and green lights all the way down.

It's all about how you frame it - why would you frame the activity you spend most of your life doing negatively?

Re: Be nice to programmers

#65
There's some irony to be found here. More likely than not, someone just like the OP built the bug tracking app that encourages clients/customers/users to give negative feedback and report problems.

This is also highly apparent in social apps (e.g. Facebook, Twitter, Yelp, etc). We encourage negative feedback when we give people a platform to do so. For better or worse, a lot of what we create is simply enabling the insatiable devil inside of people.

It sucks, but most people are unhappy and they will always look for another avenue to vent their frustrations. We just turned it into an easy-to-use textbox that's available 24/7.

You cannot expect people to be positive when the thing you gave them (seemingly, from their perspective) encourages negativity.

All that aside, you can't let people get to you. The world is getting increasingly judgmental and you just have to roll with the punches.

Re: Be nice to programmers

#66
post #30

There is nothing intrinsically negative about anything said here, just neutral things viewed in an extremely negative lens. Here's the exact same set of steps making up the "normal workflow", but framed as a positive feedback loop: 1. write some code 2. run the code 3. get further than you did before (perhaps with a new error message) 4. decide what's next and go back to step 1 I don't think negativity is intrinsic t…

That reminds me of an old story about how different people can look at the same job in different ways: A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I’m hammering this stupid rock, and I c…

I rather like this and would love to appropriate it. Is there a correct attribution to use?

Re: Be nice to programmers

#67
post #34

This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life. Chasing down bugs all the time? Why? I don't do this, and when I run across a bug it is usually a quick fix and not a big deal. The goal is not to write it perfectly without bugs. The goal is to release it perfectly without bugs, and to do this all you have to do is test your code often as you make changes t…

Sounds like you've never been tasked with working on a huge base of code you'd never seen before. If all I ever did was work on code I wrote, I could see myself thinking like you do. This is not the case for a lot of people. Maybe in this HN startup bubble, but not in the "real world" of software engineering.

That is a good point, but I do have the perspective you talk about. I started out at a web shop for 4 years, so I'd spend a lot of time in other peoples code. I then moved on to a nice little SaaS company with a 10 year old code base which had a bunch of legacy code that I had to deal with when first starting out. I had to pick up a variety of languages that I had not used professionally before. I have spent 4 years there and am leaving at the end of this week to start my first company.

But my belief is the same, the solution to the problems described in the article is time/experience, not the adoption of some pessimistic mindset. You will run into bugs when working in other peoples code, as a result you will learn not to make those mistakes. Over time you will get quicker at identifying similar bugs and will be able to resolve them quicker each time as well.

The most common answer to any CS question that you are asked in college is "It depends". So how do you resolve these nasty legacy code bugs? Well, it depends. Is this code reused a lot in other places? Is this critical functionality to the user? Once you determine how important the buggy code is, you can decide whether to solve it with a hack or a well thought out solution.

Don't sweat the bugs, don't become a Debby Downer, fix them as they rise, and keep building cool shit.

Re: Be nice to programmers

#68
I'm sad I can only give this one vote.

This theme has been on the tip of my tounge for a long time; in fact, I tell coworkers that I see every item that is in the ticket system, be it a bug or a feature, as a "delta", a change in the system to make it have some characteristic it doesn't have now.

I'll just say that stress management is one of the issues you must face if you're going to be an effective (and happy) developer. It's important to get exercise and take breaks, but it's most important to understand your sources of stress and deal with them. Sometimes you can take action, by say, getting a motorized standing desk and tall monitor arm to avoid pain. There are other sources of stresses that you just have to accept.

Re: Be nice to programmers

#69
It's times like these I'm thankful for a life lesson I was taught about 4 years ago.

I'm not a professional coder, but I do a significant amount of hacking and coding for one of my research fields (Computational Economics). I noticed this cycle too--this cycle of focusing on the negatives. It really did bring me down.

I chatted with my adviser, who was married for a number of years to a child psychologist. She recommended to him that every time he accomplishes something small, get up and walk around. Do something small to reward yourself. Then, get back to coding. This inserts a positive stimuli in an otherwise negative feedback loop. The more bugs you solve, the happier you are.

I've found this to be very helpful for me. Hope if helps some of y'all too.

Re: Be nice to programmers

#70
post #18

Try your hand at security and come back to appreciate the optimism and positivity(#) pervading the programming world. (#)relative.

Indeed. Or go work on software for manned space vehicles, or medical devices, or huge financial institutions, or anywhere where the consequence of bugs is "people die" or "national security is compromised" or "society collapses" or the like.

I wonder if you couldn't formulate a rule to the effect of the more serious the task you are working on, the less you can afford to be optimistic. When Serious Things are on the line, you have to be a pessimist, because you have to find and root out all the possible weird failure cases before they bite you. When all that's on the line is a comment on someone's photo of their lunch, optimism is a more sustainable philosophy.

Post reply on HN