bpyne

"Do you agree there's a spectrum here (with stuff like Brainfuck being on one end)?"

I'm in complete agreement with you. My contention is that a person who works with a certain language, even Brainfuck, all day every day is going to be able to read it as easily as a person who works in a more "popular" language like Java: even if it's at 4am. Anyone who doesn't work in the language shouldn't be reading it with the goal of implementing a critical fix at 4am. That person should contact a team member who does work in the language.

I'm contending that the 4am scenario, as posed by the parent commenter, is a process issue not a language issue. If a manager requires that whoever answers the phone at 4am fixes the problem, even if the person has no knowledge of the language or requirements of the module, then his/her employees should be running to another job because that manager is bad for your health and livelihood.

I can understand not knowing the details of your coworkers' modules. This has been true everywhere I worked. However.....

Where I work now, on-call was long ago relegated to nothing more than a routing task. The on-call person takes the initial call, figures out who best can solve it, and contacts the person. The guy on my team who writes only in Javascript and Python would NEVER be in the position to make a critical fix overnight in a Java module. For those of us who work in Java, reading the language is trivial but understanding what the module is supposed to do from a high level is non-trivial. People who work in Haskell daily would be the same.

This is what I tried to call out. A Haskell developer called at 4am would have no more problem reading Haskell code than I would have reading Java code. While a Javascript developer should NOT try to issue a critical patch in a language (s)he doesn't work in, regardless if the language is Haskell, Python, etc. Any organization requiring you to do so is poorly managed.

1) No, that would be ridiculous. My point is that a developer working with Haskell daily to develop an application would have no problem reading it in the middle of the night. The biggest problem for a developer, who may not have written the module in question, is not understanding the requirements for the module.

2) Early on and even then rarely. After working in a hospital writing and supporting an electronic patient chart system, I found it hard pretending that anything short of life and death was serious enough to be woken over.

Only a person from the team who wrote the code to begin with should create an emergency fix. Since any developer from that team already knows Haskell, from having worked on the code base, the criticism is ridiculous.

I can't upvote your comment enough. The use-case for a developer implementing a fix after being pulled out of sleep should be life-and-death circumstances.

"1) Production code should be understandable by an on-call person at 4 am. If business logic is buried under layers of lenses, monad transformers and arrows, good luck troubleshooting it under stress. And real systems do break, no matter type safety."

Let's assume that your on call person is a developer. (If the person is not a developer, (s)he is not going to comprehend any language.)

1) If your application is written in Haskell, the on call developer would more than likely have been involved in the code base and reads Haskell. Your assertion about not comprehending it seems suspect.

2) You have a serious process issue if a developer is woken from a sound sleep to track down, correct, thoroughly test, and promote a fix for the bug in the middle of the night. The number of cases in which this happens should be close enough to zero to call it zero.

Your comment sounds like an attempt to cast Haskell as a purely academic language because it fails a (poorly) made up real world scenario. I'm NOT a Haskell-er so I don't feel a need to defend it. I do find the reasoning behind the criticism poorly thought out.

"need to belong"..."The tendency of people with this need is to weaponize The Thing, and to wield it against those outside the movement and those they do not deem as worthy of inclusion in the movement."

So many examples of this in daily life. People do amazingly vicious things to validate their membership in a movement/tribe/religion/cult/etc.

Yup. Power user was the name we used back then. If you had a good one, (s)he could save you support time.

That's the super-user syndrome. They know enough to get themselves into a bind but not enough to get themselves out. It's difficult just trying to get an accurate description of the problem because they lace the description with theories about what the cause is.

"Please just describe the problem and, if possible, how you reproduce it. No, just describe the problem. What's happening when you press the button? No, just the problem! Not what you think is causing it."

It's a conundrum because good super-users can help less technical people in their groups. But, their issues tend to take more time to unravel.

I read only up to the point in which I had to pay to continue. Was the article only focusing on sandwiches?

If so, is that the biggest food in common for lunches between the US and Great Britain?

I tend to bring my lunch M-Th and get takeout on Friday. My takeout is almost always Thai. When I dine-in it's usually ramen. For them, I expect to pay $10-12. What are prices like for Thai or ramen in London?

People in the US prefer inexpensive. They have a certain price point they don't want to go beyond. The Eatery I described was as far from "fancy" as possible. Dishes were under $10 and were rich in vegetable and protein content. They were also very flavorful. Eating flavorful food does not make it "fancy".

How fast food proliferated in the US goes beyond "fancy"/"not fancy".

I could get behind this. But it has to be different from current mall fare. I hate chain restaurants. Food courts tend to be sandwiches or fried crap passed off as ethnic.

When I lived in Boston there was a place in Chinatown called the Eatery. When you walked into the main room it had probably 15 different stalls, all with different types of Asian food. Everything was made to order. A mall converted into something like that I could get behind.

Sorry, no, not an MS employee. I use MBP at home and would use it at work if I had the choice. But, the Win10 engineers did a nice job in making the os usable. I haven't once had a BSoD that wiped out my setup while testing software. I can go weeks without rebooting and don't experience a slowdown.

My employer mandates it so I use Win10 at work. At home, I'm macOS.

I replied elsewhere in this comment thread that Win10 is the first Windows version that I found usable.

I don't game. So, I probably don't stress the os the same way you do.

I run Eclipse, an Eclipse-based tool called Anypoint Studio, Netbeans, PyCharm, various developer tools like Git, Toad, etc. Also, I run various MS-based tools due to employer mandate. Overall, it's a pretty vanilla setup but it's all that I need to write software for my employer.

We don't run VM's or containers of any kind.

My main problem with Windows in the past has been BSoD happening in the middle of testing software, wiping out my entire setup. Win10 hasn't done it even once to me. So, I'm happy with it.

I use macOS at home but have Win10 in the office. I've been using Windows in some capacity since 3.1. Win10 is the first one I've found usable.

Going from Win XP at home to OS X, I found it astounding that my PowerBook could go months without a reboot. Likewise, my MBP astounds me daily that I can't remember when I last rebooted.

My employer's Win10 laptop is like that as well: I don't think about rebooting it anymore.

MS is on a good trajectory, finally, with its os.

I miss disk jockeys. The ones who were knowledgeable about music, played B sides, and had some personality were gems. I found a station (KSLG) in northern California that still does this.

I like Spotify and there's a place for it. But I wouldn't call it fun. Listening to a good DJ was fun and sometimes informative.

What we call multitasking is usually task switching, according to an article I read after a similar discussion on HN. The dividing line has something to do with only one task at a time being able to use an area of the brain. As long as one of the tasks doesn't use that area, you can multitask. Otherwise, you can physically only task switch.

It's not unreasonable. My team is usually in by 9, 9:30 at the latest. We take 20 minutes to get coffee and discuss issues, what needs to be done, etc. Then we set about completing tasks.

A startup I worked at in the mid-90's had people working in pairs: a server developer and a client developer. They didn't care what hours you kept as long as you didn't hold up the other person in your pair. I arrived around 9:30am daily. The client guy I was paired with came in around 8:30am. I always stayed later so I'd check in code before I left and leave a message for him about the progress. He tested stuff before I arrived and went over any issues when I got in. Then we'd work together the rest of the day. Other engineers came in at 10:30am, noon, and as late as 1pm. They worked it out with their other halves the same way I did.

I think wise managers work with the team, minding company-imposed limitations, rather than enforce personal preferences.

I can completely see it. In the hands of a controlling manager, it can be abused. My manager recognizes that we're usually in the office by 9-9:30 so we walk regularly at 9:30.

Late day meetings are great too if it works better for the team.

In my team's case, we also walk or ride bikes together at lunch. So we can also use that time if necessary, but usually we just keep it casual.

The idea behind early and/or late walks is to not interrupt developer flow in peak cognitive hours. My current manager is one of few in my career who recognizes the reduction in productivity that comes from interrupting the flow.

Software engineers have largely been nocturnal, favoring later arrival times at work, in my experience. In my team's case, all the developers are late arrivals so our manager simply works with that tendency.

There are two times of the day to catch software engineers: the start and end of the day. Usually at the start of the day we haven't gotten our minds into "programming mode" yet. By the end of the day, mental fatigue is setting in.

The team I joined - 4 developers and 1 manager - goes for a coffee walk in the morning. The manager waits for us to go through email and other communication that came in overnight. Then we walk to a nearby coffee shop. On the walk, we discuss issues and what we intend to accomplish for the day. It takes about 20 minutes.

Occasionally, we take a walk at the end of the day as well to discuss issues. When the manager calls for an end of day walk he senses our energy is low.

As I get older, I like routines in the morning. They help me get my mind in gear. We go for the coffee walk. When we get back I might read a short technical article. Then it's time to get stuff done.

Thanks for the tip. I right-clicked on a thread in Outlook and sure enough "Ignore" was there.

That's one of the ways Slack is more chatroom-like. Good point.

Email would be a bit clunkier as someone from the email thread would have to forward it to you or reply all with you in it. It's an alternative, but not as slick as Slack.

50+ here...

Email has been the major communication vehicle through my career. The work team I joined a year ago uses Slack. Our employer's official vehicle for "chat" is Teams. My team's high school interns prefer Discord. Some friends use FB Messenger. Others use text.

I have no preference. In the end, all of them can send messages point-to-point or broadcast. You can share documents in all of them. (I haven't tried it in Discord but I assume you can.) I can communicate and get work done in any other them.

Just a few observations.

1. Trying to figure out who communicated where can become challenging.

2. Better integration with "productivity" apps can make 1 less challenging. For instance, a co-worker requests a new API by a certain date. If it's done in Slack, for example, it would help to have it appear in my task list without my having to add it manually. Likewise, a friend sends a message in FB messenger about a cookout: having it go to my calendar would be helpful rather than my remembering a week later which app she sent the message in so I can put it on the calendar manually.

3. My employer is notorious for abusing email. We have message threads with 10-20 people and dozens of replies. Often I would love a way to opt out: a real opt out, not a reply with a request to Reply All minus me. Not having this feature is a deal breaker for email going forward IMO.

" It doesn't include things like lawyers and computer programmers"

When my daughter was in 4th or 5th grade they had a "career day" in which students could meet parents who were in jobs they found interesting. I offered to talk with kids about being a software developer. The organizer contacted me the day before to let me know that nobody signed up to talk with me. I was a bit crestfallen. ;-)

I didn't mean no learning on the job. The time to learn is between projects. If your employer keeps people on projects constantly, then learning happens between tasks.

COBOL/CICS was supplanted mostly because mainframes were supplanted due to smaller organizations, that wanted to use computer technology, not being able to afford a mainframe. Companies could lease time. But I don't remember it being the norm.

Mini's and then Unix systems allowed us to develop systems with newer technology. Wintel systems expanded it further.

My point is that the new technologies came about via need: it allowed more people to utilize computer technology to solve problems. As needs change, we'll continue to see an evolution of technology to meet the needs.

I'm only part way through the presentation, but I loved this line.

"And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is."

Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby, or just veg out. Experimenting with new (to your organization) languages and infrastructure pieces is something you do between projects, not during.

It reminds me of something a jazz musician said in an interview, "The audience doesn't pay to see you rehearse. Rehearsal is done on your own time away from audiences." Rehearsals are where you try new techniques, harmonies, instruments, etc.

Organizations have to find their own way of working. It's going to change based on the size of the organization, its goals, and its people. With the exception of 1.5 years in a software company, most of my organizations have been internal IT. What I find is that user areas, who initiate projects with us, often don't have a clear view of what they want but think it's going to help the organization. Our job is to build models quickly so that they can validate an idea. Only after iterating through a few models can they reliably say the benefit/cost of the idea.

A very good engineer within my organization said to me, "Our job is to get something in front of them quickly so they can figure out what they don't want." Our successful projects have been ones in which we kept to this maxim.

I think this is what the author was trying to say but I had a hard time following his writing style.

I wonder if the problem isn't how to measure productivity, but the fact that we bother to focus on individual contribution rather than how the organization operates with respect to organizational goals.

I work for a mid-sized university. We're a bit unique, for higher ed, in that we have centralized IT. Our projects support university 5-year plans. When projects do not complete successfully or are extraordinarily late people notice. If teams are hitting their goals - university goals - does it matter if every person on a team is hitting some averaged-out metric for productivity? If a team isn't hitting its goals, usually it's not due to individual contribution, it's due to poor communication, unrealistic goals, frequently shifting requirements/priorities, etc. Usually a sit down with the team to get feedback will tell more of why the team failed.

A hobby of mine is coaching youth basketball. To increase my ability, I joined a forum. Today the moderator posted a quote from NBA player Marc Gasol. Marc lamented the tracking of individual stats because the stats don't tell the story. He stated, correctly IMO, that many critical factors are not tracked and would be hard to measure the importance of. For instance, a player who doesn't score much but prevents his defensive assignment from being a play maker (play makers are more than just scorers). Or the player who sets up the plays that allow other people to score (for those familiar with basketball, think screens/picks). Or the guy who is on the bench but helps calm down players when their team is down.

I've come to feel the same way about IT teams. A win is a team win; a loss is a team loss. In both situations, many factors came into play in order for the outcome to occur. My experience is that individual productivity stats don't give you a clear idea why the outcome occurred. In the end, it's all about the success of the organization.