shermanyo

Backing up what you said here, I've played a few online games with (at times) abusive communities (DotA, Overwatch), and in my experience:

- Games go for 30-60 minutes on average, and generally have a clear winner by the halfway point. Players are forced to sit through a defeat, building frustration.

- Games rely on team coordination on top of individual skill, so players who are scoring high (kills, etc...) may not actually be helping complete the objective.

- On death, there is enough downtime to vent frustration at your team, and blame them for the bad situation that caused your death.

- People often try to get the rest of their team to side against an individual, calling them out as the cause of other players dying / losing objectives.

It can be extremely toxic (to the point I've moved on), but I found pushing back with civility and calling people out often helped the situation.

Whenever I noticed it starting, I'd jump in and tell the frustrated player to take charge. I'd acknowledge the valid issues they call out, and try to reword them constructively and focus on the team rather than the individual. (eg: "Don't run in until we're all there to support you, we'll follow you now and see if we can outnumber them", or: "Try moving over there, their sniper is really good, and is protecting the area you were just in")

This has popped up a couple of times and I never got around to confirming either way. I always went to the trouble of syncing to rule it out before moving on. (sometimes annoying on an isolated test network)

Thanks for taking the time to link the relevant section of the RFC. I'll remember this next time (or at least know where to check quickly ;) )

Hahahahaha, 6 media corporations? Six? I wish!

Name just one (in Australia) that isn't owned by Murdoch or Fairfax :P

Just a head's up: Presto was owned by FoxTel, and was shut down this month.

Stan seems to be a good competitor, but that's only comparing it to the Australian Netflix library. I'm of the opinion that all competition has done is split the market, as they fight over the same set of exclusives.

I'll often browse US Netflix rather than switch between Aus Netflix and Stan to find a movie I've seen previously. US Netflix seems to have 90% of the missing content Stan offers over Aus Netflix.

At the end of the day, my biggest reason is that few of those work/look/act/configure the same as they did 10 years ago, and will undoubtedly change how they work/look/act/configure in the future.

This isn't a bad thing, I just prefer to stick with what I know how to use efficiently to do the tasks I've done before.

One thing to keep in mind: I don't just use a different set of tools, I have a different workflow. Vim rarely takes up a full screen. (well, half now we've all agreed on widescreen monitors...)

As a quick breakdown of working on a project:

- I usually have a 'command' terminal, where I run build commands, execute / debug the app, manage project files, etc... (usually in the root dir of the project I'm working on, so paths are relative and easy to work with everywhere)

- I have a 'main editor' terminal, using Vim to open multiple files for editing, splitting the window and switching buffers on the fly based on what I'm doing.

- I have a browser window with tabs open to various documentation/reference pages for the code I'm writing. This gives me my 'intellisense' equivalent, I guess.

- I might open terminals temporarily to display other code, etc... when I want additional references displayed. (but only ever edit from the main editor window)

- I use tools like cscope (or even just grep) to browse my source code, which I can even do from the editor.

- I generally write a build.sh / run.sh / clean.sh I'll add to as I go, which wrap things like CMake, Make, lint tools, etc...

The biggest perk is that I can work in 100% the same way from any system with an SSH client, with zero change to my workflow. I can reconfigure my entire development workspace on a clean system and be productive with a couple 'git clone' commands and running a shell script to 'yum/dnf install' a couple standard development tools from the default repos.

I don't mean this defensively, I'm genuinely curious... What do you think an IDE gives you that other tools don't? The first two that come to mind are a tightly integrated build system (eg. creating a new source file automatically builds and links it with the project), and the GUI design tools that generate the relevant class files. (Those could be huge factors for some people)

Is it simply the all-in-one packaging and integration between the tools?

Thanks for taking the time to reply if you get through all that :)

Your question specifically called out 'learning' as opposed to 'focus', so I'm going to offer a slightly different take to what I've read below. (all great advice, especially daily management)

I've found the biggest factor is having a clear picture of what I'm trying to learn, with a practical use case / example to work on, which ultimately becomes my reference point.

Learning then becomes a process of making the example work to achieve the expected result. A series of problems I can tackle, using my "mental skillness" rather than fighting it.

There is overhead in context switching, but I balance that with the mental effort of fighting distraction.

If I feel like I'm struggling to focus on my current task (say, reading about "High Availability and Failover across a set of database nodes"), I'll switch to a different task that's still related to getting my example working (maybe draw some diagrams to visualize the pieces I've learned about so far, or set up a few servers and install the database software ready to configure, etc...).

The trick is to try to make constant progress relevant to what you're specifically trying to learn, but vary the sort of stimulus you're feeding your brain to keep yourself engaged.

I've come to see my subconscious as my personal OS:

'struggling to focus' is like blocking that thread on I/O or some mutex lock. I see it as an indicator to give some CPU time to some other thread (ideally all part of the same high priority 'process'), flush the buffers, etc...

Agree with everything on this list, especially the focus on rest, and walking on breaks (physical distraction vs mental).

I've found the latter especially helps to 'reset' when I start to get a bit fuzzy. I think its a combination of the Gruen Transfer coupled with forcing myself to snap out of whatever I'm spinning my wheels on.

I'm curious if some of the dissonance comes from basing everything off the root note of the key, rather than each chord in a phrase? I'd be interested to hear the results on a piece following this algorithm in comparison.

> I have made many mistakes since, just never the same mistake. And with the years I take better and better precautions, scale horizontally, test backup restores etc. But mistakes still happen, just don't panic, and don't try to be the midnight oil hero :)

Perfectly put. Thanks for sharing.

thanks for sharing :) its great when an 'unscheduled verification of backups' goes well ;)

oh wow, number 2 was amazing. I know the exact feeling.

That (well deserved) condescending "just-for-you" protection, then the sheepish admission that "I did it again anyway, I'm so sorry" :P

ouch!

any of those will do nicely haha. thanks for sharing :)

I've heard some horror stories from mates working in data centers, where a simple route or firewall change knocks out a huge number of customers :/

We had a pair of VMs that switched hostnames in DNS at one point. (ie. the hostname 'test-1' resolved to the VM with the image named 'test-2')

someone would inevitably restart the wrong one from the VM host, thinking it was the one they'd been SSHing to :/

There should be a name specifically for this, like "VM Host Archaeology"

> 10 years later, I was still getting svn blame based questions "about this code you wrote (in -r 6)"

That's fantastic haha

oh wow, I've done this before too, multiple times. Deleting _all_ the backups instead of a specific one is a heart stopping moment...

I love these sort of threads for exactly this reason. I always seem to walk away with a better understanding of some tool I've used for years.

I see it as mistaking software for the subject.

I'd guess a lot of people think the above, when they actually want "software that makes _them_ more efficient."

For example, it may be more efficient for the software to break up screens into tabbed views, but certain users may find a single screen covered in controls more efficient when actually working day to day.

This is really interesting to me, how different people view programming at a conceptual level.

My current view (it changes every couple of years) is that as a skillset, programming is primarily based on planning and management, most akin to logistical management and orchestration. (we're just lucky our workers are CPUs and resources are memory/bandwidth vs workers you have to individually train, and physical resources that are permanently consumed)

The focus of a programmer's work, and the skills required include:

    - domain knowledge and understanding of the work being done  
    - developing use cases and modelling a solution, often built from well defined and understood 'components' and relationships between them (eg. factory/production, shipping/freight, warehouse/storage, storefront)
    - defining processes and procedures to deal with the various states throughout the project's lifecycle  
    - logic and control flow through these processes including synchronization and validation  
  

The more I've looked at examples in areas outside CompSci, the more parallels I've drawn to general project planning and management skills, vs those more artistic or scientific.

In case it's unclear, I _am_ talking about writing code, and not software development in general.

I often think of my data model as a physical system, and its behavior in terms of real world systems. As a simple example, I visualize the function processing a FIFO queue as someone working a specific station in an assembly line factory: their job is to take incoming pieces of a known, expected type and do _something_.

I find this helps me "zoom in and out" mentally, grouping things in context with some understanding of what's going on internally, while still treating it as a "black box". (eg. you can still picture what's going on inside a "factory" when you're looking at it as a whole, with several inputs and the produced output)

I think people are dismissing / overlooking your comment, but I've seen exactly this time and time again.

Anecdotally: I developed a drinking problem in my first few years of work, which I used to deal with anxiety and depression as I failed to find my feet and seriously questioned dropping out of software development.

I was eventually diagnosed with ADHD (inattentive) and through treatment, experienced a complete life change.

I stopped drinking excessively, then almost completely. I never tried to address the problem directly, I just lost any desire to drink outside of a normal social context. Even then, I rarely have more than 2-3 in a night.

I'm on stimulants for treatment, but take breaks some weekends and over holidays. I've always been a coffee drinker, but now I'm conscious of how much I'm drawn to it for the positive effects I see.

I honestly think it was the only reason I got through university (before diagnosed / treated for ADHD). I was using caffeine in the same way I use my current medication, to fill the same gaps.

I don't want to comment on the effectiveness of self medication, or anything diagnosis related. I just find it interesting the correlation between certain personality types and the class of drugs they seem to be drawn to. I think it offers a lot of psychological insight we haven't really looked at in detail.

I love the idea of the touchbar (that is, I'd get an external keyboard with one if it had the Fn keys too...).

I can think of a lot of uses for it, though maybe not making full use of the display capabilities. When I first saw it, I immediately thought "programmable ribbon controller".

Think of a virtual slider/fader that can output absolute position or relative movements, with (here's the kicker) the Fn keys selecting what the control is connected to.

For example, iTunes could use it for seeking position of the current audio. Tapping along the ribbon would drop you at that point of the audio (like moving and dropping the needle on a record). The Fn keys could switch it to Low, Mid and High EQs, let you scroll through your folders and playlists, etc...

Really? It sounds like a good fit to me, maybe I'm missing something?

I love this question! I'm a DevOps engineer who came to my role through a combination of test automation and test network management, and a keen interest in tinkering with technology stacks. I love what I do and can't recommend it enough to new graduates, who may not even know of the role.

To build a portfolio, I would suggest the following:

    - Create a document describing a small tech stack:  

      > Outline the systems (or list of docker containers)  

      > Draw a network diagram showing IPs / subnet(s) info  

      > Describe the OS(s) and base node configuration (ssh, NFS, etc...)  

      > Outline the software stack (on each system), describing connections between nodes (eg. Apache web server with PHP, connecting to Postgres on port 5432)  

    - Create a github repo  

      > add the above document as the README.md file  

      > add a SETUP.md document (or add to the README) with steps to setup a local ansible workspace, and deploy your stack with your configuration scripts  

    - Set up a local (or cloud) environment with your Jenkins pipeline, and document a deployment (with screenshots) showing a working stack configured from a set of clean nodes.  

    - Expand on what you've made (create a new repo for each! think of them as new projects with a different set of requirements, even if they build on what you've previously done). Try to focus on one thing at a time:  

      > SSL everywhere  

      > OS hardening  

      > failover / clustering of the database  

      > failover / clustering of the web/app server  

      > load balancer in front of the web tier  

If I saw the above from anyone, I'd be impressed. If you have any questions, feel free to message and start a conversation offline. Best of luck!

Just a heads up, in case you haven't seen it. Go has pretty nice handling of pipes for certain use cases. HTH

http://blog.ralch.com/tutorial/golang-command-line-pipes/

My guess is the "whiteboard interview" morphed over time and lost track of the initial intent and value.

I bet initially, code wasn't a focal point. Hiring for a position that _requires_ an understanding of certain algorithms and/or data structures, it can be a quick and simple way to outline or walk through examples at an abstract level. (both to test knowledge of existing examples, or development of a solution to a new problem)

This actually _removes_ many of the overheads associated with code: syntax, scope, state, context.

I feel really bad for Dropbox and the reaction this got. I'm probably ignorant to a lot of issues minorities face, so excuse me if I appear insensitive to any particular group, that is definitely not my intent.

I saw the photo and my first thought was (no offence!) "cool, they aren't all < 30". I was a little surprised, I assumed they'd be a group that built their startup out of college for some reason.

I then noticed the male/female count and thought that was the focus of the "diversity" tag. "that's great, but nothing to brag about... I've been on teams with similar ratios, but maybe it's less common in smaller companies?"

I'd started scrolling and realised this was posted to highlight the backlash about the lack of black and hispanic (apologies if either term is wrong, please correct me and I'll know in future) employees.

I won't comment on the criticisms as I don't understand the issues faced over there (I'm non-US fwiw), but I do want to offer my perspective in isolation of the other issues.

When I look at that pic with diversity in mind, I don't see as clear a divide as I do in most groups. I compared it to my recent xmas parties (at what I consider a diverse office), which tend to separate into "the old guard", "new hires", "parents with young kids", "under 25s", the "smokers" and probably a few others. It's easy to forget diversity spans more than race and gender.

I'm going to assume Dropbox had good intentions. Maybe they'd seen an increase in an area they focused on (eg. gender) and were proud of their progress? Encouragement could help expand on that and improve the situation for groups who don't feel represented.

From one office to another, I hope the team had a nice end of year celebration and enjoy time with family and friends over the holidays.

I strongly believe that everyone could write useful, nontrivial programs:

- in a domain that they understand

- if given suitable tools

I've seen musicians do things I couldn't begin to draft an implementation of, thanks to domain-specific environments like Max/MSP. Their understanding of audio mixing, musical timing, and signal processing mapped to the development environment _and_ workflow intuitively.

It's humbling when you struggle through basic DSP, then a guitarist shows you a complex algorithm and shrugs it of with "its just like lil effects boxes, dude."

Watching him debug was eye opening too. As if tracing a buzz on his guitar's signal path, he patched in after each node to confirm the output at each step, like I'd do with a debugger on each line of my code.

His context was so beyond my understanding though, picking up on issues further down the signal chain by noticing frequencies that would feedback, clip or cause phase issues. It really showed me that an understanding of the domain and context of what you're trying to achieve trumps nearly everything else.

> Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it's not a comprehensive solution, and possibly error-prone.

I've done the same for far too many projects, both existing and green field, and always ran into the same issues:

- manual sync (even if reporting is scripted) of every detail, info always ends up stale and often causes more issues from someone inevitably following it as a reference.

- additional overhead and maintenance, tied closely to the point above.

- stale / unaccessible links (file server accounts, etc...)

- change history and supporting multiple versions / environments in parallel

I've come to the personal conclusion that it's easier and faster to bite the bullet and spend the time on your build and deployment steps, with the points you listed in mind.

With a Jenkins server, you could create a project that simply watches your current build directory and creates a new Build with its own Version Number, and a single archive as a Build Artifact containing your changes, including the current versions of your config files, required packages, setup scripts, and possibly a current snapshot of any relevant documentation.

This gives you visibility of exactly what was contained and possibly run (if your setup/update is scripted) for each deployment / update you perform.

You can build on this over time until it contains all the info you require about a particular snapshot of your stack.

Next, you can build a list of your servers (and environments) and track which Build from Jenkins you've installed to each.

(I believe Jenkins has plugins for that, but could be tracked elsewhere)