bpyne

She brought up an interesting point: asking your colleague if (s)he wants recognition.

Sending recognition is usually a decision made in the moment. Asking permission makes a process out of it. Having a process reduces your motivation to send recognition.

Her five reasons are spot on. But I'd like to add that people should understand their work environments and the politics involved. It's easier with small to small-medium sized organizations where you know all or most of the managers and their quirks and know the politics at work.

My environment is small-medium. Part of what we're judged on is helping colleagues. The managers are all onboard with it. When a colleague from the Unix admin team went out of his way to help my team I didn't hesitate to send his manager a message in praise of the effort. Getting a colleague in trouble for taking time out of assigned work is not an issue.

So much good in this short piece. He sounds like someone I want on my team.

Users who work with IT often tend to give better descriptions and test cases. Quite often I need more information though. He's right that you try not to bother the reporting user. Sometimes there's no other way.

Reproducing a bug is often the most time-consuming part of a bug fix. It's doubly difficult when you have a shared test environment and the bug leads you into a shared data set. For instance, we have a scheduling table that's used by many applications. I can't change the data, even on test, because it can easily mess up other teams. So I have to make a copy of it to my schema, alter data, and point the code to the altered copy.

"If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error."

Yes, these developers exist. I worked with several over my career. They are frustrating because they leave damage for other people to fix, often at the worst time.

"Finding the exact cause of a problem, and looking at all the ways to get there can provide valuable insights."

Yes a thousand times. Bug fixes are opportunities to learn more about a system and, often, the user area for whom we wrote the software.

"I want a fix that isn't likely to cause confusion or other problems in the future."

A good fix takes into account the overarching software design and fits it if possible.

"I don't want a bug to be found in the future and for me to have to come back to this code when I've mentally moved on. Context switching is expensive and frustrating."

Writing software is building an abstract machine in your mind. These machines get complicated. Even when you're fixing a system written by someone else, you need time to "load" the machine into your mind.

The only time I don't like fixing bugs is when I'm against a deadline on writing/modifying another system. The context switching is a deadline killer. But, it happens. Nowadays I let the project manager know that I'm switching to a bug fix, give an estimate of how long I'll be away from his/her project, and my best guess on whether or not it'll cause a deadline slip.

Great post.

I didn't invent it.

https://en.wikipedia.org/wiki/Deep_state_in_the_United_State...

I discovered it on July 4 when people I passingly know on FB took a pledge to QAnon. Looking up QAnon brought me to the Deep State conspiracy belief.

https://en.wikipedia.org/wiki/QAnon

One characteristic of it is a deep distrust of "the media".

I suspect we have some "deep staters" in attendance. Everything you know, you don't. Everything you believe is false. A liberal conspiracy exists and it's hiding in plain sight.

If you ignore these "throw the baby out with the bathwater" comments, some good discussion is being had.

"Philosophically science is about being interested and studying broad range of topics and areas to judge everything for yourself and make your own conclusions, not trust expert opinions."

Not quite. It's observation of the world around you. It doesn't preclude experts' opinions, it takes them into account. Reinventing the wheel isn't the goal of science. The goal is to understand why a circle might be the best shape for rolling and under what circumstances it might not be.

More specific to current times, ignoring the advice of epidemiologists with respect to masks and social distancing is proving to be costly in life and economy.

"In my experience, whenever I have to rely on an expert opinion I usually feel bad later when I acquire more knowledge in the area myself, as those opinions are almost always wrong."

Care to share a specific example from your life?

Excellent, thought-provoking piece that comes at a good time for me. I've been looking at Python's unittest for a specific system I've been developing over the course of 12 years at work. It became clear recently that we need more automated tests. However, as I started to design a test suite in unittest, the scope of it became overwhelming. Looking at it as a suite of functional tests makes it more reasonable to write.

I enjoy learning about the industrial area I'm in (higher education). I enjoy creating software that people use daily. I enjoy creative problem solving. I enjoy learning how different organizations fulfill their reason for being while handling operational details. I go to work for these reasons, as well as, a comfortable pay.

I don't mind working. I would just like to do it less. A few years ago I dropped to part-time in order to be in a grad program in CS. I found that 25 hours provided me with the perfect life balance.

I think Jemisin is moving SciFi/Fantasy toward a point in which the hard line is becoming irrelevant. In general, I can't tolerate SciFi for much the same reason that I'm bored with High Fantasy. Jemesin brings enough of each into her stories that I can enjoy the science and am not seeing an ill-defined magic system bail characters out of poor choices.

Jemisin listed Octavia Butler as one of her biggest influences. I read a few of Octavia's books. The influence is clear. If you enjoy Jemisin, you'll enjoy Butler.

Rothfuss had an imaginative magic system in the Kingkiller Chronicles. I'm hoping that he continues with the system even if he doesn't finish the series.

An interview with Brandon Sanderson peaked my interest in Jemisin. He said something to the effect that she is trying to move Fantasy into a new direction. At the time I read it, I had finished the Malazan Book of the Fallen, which in itself is a large departure from High Fantasy, and was in search of something other than a loosely-defined magic system that gets protagonists out of every tough situation.

Jemisin provided what I was looking for: second-person narratives, magic systems that are defined and have (loose) roots in science, plot twists, and great character development. It's also chock full of moral ambiguity. Her books are also short. After reading MBotF, I felt like I ran a reading marathon with books general being 1000+ pages. I wanted someone who could say more with less.

Jemisin listed Octavia Butler as a strong influence. So, I read the Parable books and am now reading Fledgling. The influence is clear. Butler's books are brilliant and so different for their time. Her name is really not mentioned enough.

I have to mention Joe Abercrombie as another author who is moving Fantasy away from magic-driven plots. Brilliant author.

[EDIT: first-person should have been second-person]

Reminds me of a snarky comment I read, "If you love doing something, keep it as a hobby or you'll begin to hate it."

There is bad code in everyone's repo. Several of my repos are from courses in grad school. From a software engineering standpoint, they are horrendous. But, they solved the problem the professor assigned and taught me what the professor intended by the assignment.

It's probably more helpful, in evaluating a developer, to see a progression of thought rather than shiny, functioning code.

Thanks. Multiline certainly raises the value of a REPL.

Good question about the value of a REPL to Python. My first experience with a REPL was the SQL*Plus tool from Oracle. I don't remember it being called a REPL. But, as I read about Common Lisp's REPL, I realized that I had been using one.

Early in my experience with Oracle's DBMS, I found the REPL handy to work out ideas. But a REPL is essentially a single line editor from which you can evaluate expressions/statements. As my ideas grew, the REPL became more of a hindrance. Having a full screen editor became more necessary.

Nowadays I work out all ideas within an IDE, firing up the REPL only for quick data checks. So my answer is that a REPL is helpful but not necessary.

Most of the "Belgian-style" beers I tasted have been crap. Recently I tried Allagash White and was pretty impressed with it. But, whenever possible, I just go with an actual Belgian beer.

Back in the late 90's I fell in love with a Belgian beer called Moinette that came in a large bottle with a cork on top. It had a high alcohol level at the time. Loved it! To this day, it's still my favorite beer ever.

I supported American craft beer since the mid-90's until a few years ago when everyone went nuts with hops. American breweries seem to have become a copycat industry.

Nowadays I'm going back to European beers. In particular, I'm looking for German doppelbock these days. But anything from Belgium is usually excellent.

Someone well-known in the IT field wrote about software reuse in the large vs. in the small about 10-15 years ago. The gist was that reuse in the small is a success, i.e. it's fairly simple to write a function that developers reuse within an application. When you try to generalize use beyond a certain context it becomes significantly more complicated to be successful. I think the motivation for the post was issues in object reuse in OO development. I'm trying to find the original post.

John D. Cook's post shines the light once again on the difficulty of writing reusable components.

I suggest looking for articles in major US publications starting with NPR's site. There's just too much to cover in a comment.

Just as a synopsis, systemic racism became a more subtle segregation. POC (People or Person of Color) were systematically made to appear more violent and criminal-like over time. Combine that notion with an idealized notion of the police as hero figures and you have a recipe for rationalizing violence against POC.

Mobile phone videos allowed us to see from the victim's perspective just how brutal police have become.

"How it happens that all those mayors and sheriffs are still in the office if police brutality is such a big issue?"

To this point, you need to understand about voting districts and how POC voting power has been diluted and prevented over decades.

Please see my comment to allannienhuis.

Please see my comment to allanniehuis.

Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.

I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Either the requirement wasn't specified well or a change of circumstances requires it to work differently. In either case, it's a request for modification not a bug. Your analogy should help me explain the difference.

CE mixes low and high level concepts well. I've never had a hardware class but have a copy of Tanenbaum's hardware book. It gives me hand-wavy notion of how the processor operates. But I'd never apply for a hardware programming job. Eventually I'm going to take a class in computer architecture.

While I used an "or" in my statement the reality is that most CS programs give a smattering of different CS areas including theory, SE, and hardware. SE is often one course in a 4 year program. A developer simply can't develop the skills for SE in one course.

When I was in grad school for CS I had a course with the department chair. I had been in the field for 20+ years at that point. One day she asked me for feedback on how to improve the undergrad program for students who want to go into the field. My response was a separate track that required practical year-long projects requiring SE skills. Each year the project could get progressively more involved. Students in this track would still need courses like data structures, algorithms, and programming language paradigms. But they would apply the knowledge from them to practical projects.

Section 2.4 of the paper gave me a chuckle. Like Rich, I've yet to write a program that didn't involve some kind of database. Organizations care about data not programs. Writing programs just gives them a way of applying organization-specific rules, in the way of transformations, to the data.

Your comment harks to a much broader concept. Are Computer Science programs supposed to produce software engineers or people grounded in the theory?

My own opinion is that separate tracks should exist.

Grading students more harshly without modifying the focus of their studies simply won't produce better people in the field.

"Programs are not designed to be readable, they are designed to solve a problem."

Programs are written to solve a problem. They are designed to be understood by others who might have to debug or modify them due to new requirements.

"No factual basis" is more accurate with respect to the particular example.

I think it's a good thing to hold public figures accountable. Politicians, in particular, need to be held accountable due to the large amount of influence they have on our society. When Twitter, for example, places a warning on a Tweet to warn readers that it contains provably false statements, it holds the Tweeter accountable and that is enough reason to do it regardless of the changing minds argument.

As far as changing minds goes, I think there's a swath of voters who sit in the political middle and they don't fact check. The swath is large enough that they can influence elections. It's critical to make sure they don't get influenced by politicians who make up facts on the spot.

A friend of mine and I commiserated last week about the difficulty of debating with people on political issues. We noticed that people can make up "facts" quicker than we can fact check. You would think that the onus would be on the person making an argument to provide proof. But that standard of argument is long gone. The proof seems to always be on the person who says, "No, I don't think that's right."

No doubt. Even if we increased the pay or found another way to attract people as deliverers, grocery stores need to solve inventory and order picking. They won't keep delivery customers when they can't fulfill 40% of items that a customer requests for delivery. For anything they can fulfill, people picking orders need to understand acceptable substitutions without having to be trained by the customer like an ML system.

My family used grocery delivery for 5 years with a lot of satisfaction. We had two people picking and delivering. One of the two people was a former chef and the other grew up on a family farm. They selected produce and made substitutions on an expert level with little feedback from us. We paid $5 for delivery and they never accepted tips.