hobojones

How does the touchpad perform? I'd love to move away from Apple, but don't want to spend the money on a laptop to be disappointed with that aspect. My experience with non-Apple touchpads has been sub-par so far (looking at you Dell), and it's one of the factors that keeps me ensconced in the Apple ecosystem.

Location: Oregon Remote: Yes Willing to relocate: Yes (Oregon, Washington) Technologies: Python, JavaScript, OOP, ServiceNow, Selenium, Jenkins, Linux, Teradata, Ansible, git, Perl, shell script. Resume: Upon request Email: nate.beach [at] gmail.com

Two years experience as a professional software engineer, another seven as a Linux admin.

I'm a self-taught software engineer working to fully automate what are currently complex, human run software upgrades. In less than a year I've become a key member of my current team and am a scrum team lead.

I'm passionate about improving code quality and tools, automation, and creating standardized, repeatable processes through software.

As a self-taught engineer, I'm always seeking out new areas to grow and expand my understanding of the field. I'm relatively agnostic about where or what my next move will be as long as there's ample room to learn and sharpen my skillset.

I spend a fair amount of my spare time writing software. Most of my side projects begin with the phrase "I understand how this works in theory..." I'm currently teaching myself Go.

If you're interested in CSNY history, I highly recommend checking out the Best Show side podcast, "So Far," which recaps CSNY and related albums year by year.

As someone who was aware of CSNY and knew some of the more popular Neil Young stuff, it's been a great way to explore their catalogs in a somewhat directed manner. https://thebestshow.libsyn.com/so-far-episode-one-19691970

A few years back while working as a Linux admin I sent this to a newish co-worker who was struggling. They were an older Windows/DOS person and had little familiarity with UNIX. I thought this would be an easy way to practice completing tasks via shell and to demonstrate the possibility therein. I checked in a few weeks later and my co-worker never went past looking at the first page and saying 'This looks neat' - unsurprisingly they were let go about two months after I left.

The NCR/Walmart relationship was fairly strained during my tenure. Given the sheer number of stores/sites that Walmart had and NCR's own problems, it was not always possible to provide the quality of service people might expect, especially with a smile. From a FE perspective, working on networking gear at Walmart meant that you were out at 11pm at night (typically after working 10-11 hours already and spending an hour or two onsite waiting for the part to arrive via courier) and your primary concern was to get the job done and get back home. The worst was to plug a switch in, watch it not power up, and realize you'd need to be back in the same spot at three or four hours later to try again.

Walmart must have been an interesting place to work during the late 90s, early 2000s - I imagine that most everywhere they had to solve problems at scale before scale was a considered a thing. I'd be very interested to see how the solutions created in that period match to best-practices today, especially since outside of the telecom or perhaps defense worlds there probably wasn't much prior art.

As for the Perl application, I probably shouldn't say since I'm still employed at the same company and I know coworkers who read HN. If you're interested, DM me and I can at least provide the company name and some basic details.

In the early 2000s I was working as a field engineer installing/replacing/fixing network equipment for Walmart at all hours. It's pretty neat to hear the other side of the process! If I remember correctly there was some policy that would automatically turn off switch ports that found new, unrecognized devices active on the network for an extended period of time, which meant store managers complaining to me about voip phones that didn't function when moved or replaced.

I've been told that NOAA uses tape to stream time series weather data into long-running simulations.

Our failure rates were consistently much higher compared to Backblaze, usually 25-30% higher. I never did any detailed analysis, but I'd chalk it up to a couple items. First, the stock of drives were not rotated out as frequently as I understand Backblaze does. The overall workload on the clusters was extremely heavy, but not consistent across all drives in the cluster, resulting in localized 'bursts' of activity. Finally the datacenter where the clusters lived used evaporate cooling and was located in a hot, dry environment surrounded by very fine soil. During the summer the machine room was Georgia level humid, and powering on any piece of hardware would usually yield a small cloud of dust.

I concur - I used to work with a set of clusters totaling ~45k drives and it was always fun to compare failure rates (especially on a per model basis).

Once I became aware of Newegg and other online retailers, and trusted shopping form them, it was the end of Fry's for me. The Fry's close to me always had terrible products - off brand motherboards, orange stickered components, etc. For a period Fry's was my place to pick up emergency Cat 5 and other random components, but Home Depot/Lowe's sells quality product at far more convenient locations. I last visited the Renton store a few years back, hoping to find some unnecessary necessity and left disappointed. The store was under stocked and in disrepair. The general quality and quantity of goods had diminished remarkably. I was near the San Diego location a few months back with time to kill and decided it wasn't even worth it to wander around in the air conditioning for a few minutes.

Thinking back, Fry's was a perfect place to spend my teenage years - I had little money, and not enough technical knowledge to be a discerning consumer. As an adult it no longer serves its purpose - I can afford to buy higher quality goods, and have the time and knowledge to find them.

Congratulations! It may not seem like a big accomplishment, but it is. It's one thing to toy around with a language, but creating a fully realized product is a big deal. There's nothing that compares to that feeling when you load up your project and it just works as you expect it should. You should definitely walk around the next few days with a big grin on your face :).

Any time management uses the phrase 'other duties and responsibilities,' and anytime management is suddenly willing to implement an idea they previously fought against.

A few days after switching roles and organizations within the company from regular system admin work to my first real development job, my old boss realized they were completely unprepared to continue without me. Due to the overall importance of my former customer to the company as a whole I was horse traded among senior management back to my old organization and role on a part time basis under the 'other duties and responsibilities' clause of my employment contract.

Prior to switching roles I made the case that the company should back-fill my position due to overall workload, the likelihood for burnout among my old teammates, impact to customer, etc (the original intention was to drop the role via attrition). I knew that something was up when my old manager was all excited to tell me that the company took my suggestions seriously.

As for how I dealt with it - unfortunately I bent over and took it. I have a myriad of reasons as to why, but the most salient is I feel I need the development experience and don't think I'd be able to find job elsewhere just yet. This has definitely accelerated my overall plans to leave the company entirely, but in the meantime I'm trying to milk all the experience I can from my new role and am preparing to quit at the earliest possible moment.

The silver lining out of this is that my partner, family, and friends have all been incredibly supportive. Additionally the team lead on my new team understands the situation I'm in and is trying very hard to present me opportunities to grow and expand my skill set even though I intend to leave the company in the future.

The company I now work for does something similar. We sell our product at what is essentially max capacity, capping memory/disk space/CPU per the contract. When the customer needs the extra capacity or wishes to upgrade, all that’s required is some settings changes and a restart.

Former NCR tech here. I can confirm the parent’s comment - we’d routinely have to validate/ensure jumpers based on entitlement. As for recovery, I worked for NCR once they regained their independence from ATT and they were still running themselves into the ground. By the time I left (around the era of the 7878) things improved slightly.

I work on a large, legacy codebase (the oldest modules date from the mid-nineties) that's slowly being rewritten from Perl into Python. A handful of developers have been involved with the project from the beginning. Looking at the long term contributors, readable or un-readable code seems to be more about the person than the language. Unsurprisingly, the person who produced the most unreadable, unmaintainable code is now doing the same in a new Python only project.

I've always tried to look at programming in a similar manner as writing research papers, your ideas are no good if no one understands how they're put to paper. Explicitly stating your intentions is better than assuming the reader knows the subject matter. If something is clever, overly-compact or your reviewer expresses confusion, rewrite it or at least spend an extra line or two in explanation.

At the language level, I miss Perl's handling of regexps and shell commands (which consist of large amounts of this codebase). Python requires a fair amount of overhead to handle both and always feels a little clunky. While I'm far more fluent in Python, I typically reach for Perl when needing to quickly handle log files, automate shell tasks, and prototype ideas. On the flip side, now that Python supports type hinting, function signatures are much more valuable, and overall I feel I can write far more robust tests in Python than Perl. Given that the direction of the project is to move from a collection of one-off scripts that just kept on growing to a tested, maintainable, modular codebase, Python is the better choice.