jecxjo

I wouldn't imagine you'd get a lot of performance boost from the change. You'll see battery life but that assumes they aren't looking to run a crazy number of cores to make it compete with the x86. And they only way that massive core counts help is if the software is designed to utilize them correctly.

Its not that all users are devs. Its that all devs might not be able to make their software work well under that environment.

I think more people need to have a kernel hacker mindset. We are getting to the point where everyone is working so high level that they just assume you can swap out the Distro/Kernel/Arch and it will not only "just work" but will work exactly the same was as your home system. While your simple applications (not attempting to optimize or really push the limits of your system) you might not run into issues initially but when you try push things you'll inevitably run into the problem.

The fact that we're talking about ARM makes this even more important. You're having to compete against x86, which requires increased core counts, and a lot more optimization and potentially even redesigns of your software to make your higher level environment to be perceived equal to x86. Businesses will need this, your boss will ask if ARM is as fast as x86 and they won't care to quibble about technological differences if you can't just get the same output speeds as their old, trusted hardware. There is only so much your language can do to cover your butt. At some point you'll have to be aware of your environment to compete.

The more I follow SCOTUS rulings the more I think this happens quite often.

Respect is not quite the word I'd use. Yes you have to put in your time, but politics play just as much a role in SCOTUS appointments as any other branch. The major difference is that the appointees do not pander to the public for votes, rather they pander to those we have voted into office.

In my last job I had two realms of development. The first was strictly based on what the company had been doing for years, what we expect new hires to know and what we touted as our language of choice. Embedded world that was C.

The second realm was languages that I picked purely because they filled a niche better than anything else. Often these were side projects, or tooling, or things that I could sell based on how quickly and efficiently I could get up and running with X language that would save us money even if we eventually had to replace it if no one learned it.

I used F# for big data processing because I am an FP guy and they wanted .Net and I could do data manipulation like nobody's business. I used tcl/tk because I needed a super quick and dirty UI for tooling that I could quickly update to add new features. I used Racket when meta programming would hugely benefit me.

The problem is that for a lot of our jobs we are stuck with realm 1, the things we can't change. This is the area where we end up pitting languages against each other because they end up used way more than realm 2. You have to push really hard and hope someone listens but more often than not you just keep on doing what you're doing.

I worked on a huge JVM based project and even though no one in the company knew Java there was just no selling upper management on using Clojure. FP would have reduced complexity, meta programming and dynamic code generation would have made it much more robust without a lot of effort, but it was just too foreign (or at least not advertised as being used in places well enough), too new, and when you Googled it the "major" issues developers had scared everyone.

Pregnant wife and a toddler so my home time is skewed. Up before 6 to play with the kid, make breakfast, load of laundry, load of dishes, etc. Bus around 8:30, at work around 9. Work til 4:30, skipping lunch every other day. Then 30 mins back, errands, cooking dinner and finally relaxing around 6. Play with the kid til I put her down around 7:30 to 8:30. Hang out with the wife until she goes to bed around 10.

This is when my second shift starts. I pick up the kid's area, clean the kitchen, dishes, laundry, and whatever other stuff is left over. After that I do another 2 to 4 hours of work depending on when things are due, late to the bus, early to leave because of family stuff. In bed somewhere between 1am and 4am.

I keep track of my life in todo lists. Got a notebook and a pen within arm's reach at any given time. Zero Inbox/Bullet Journal/GTD my entire life, work and personal. I also naturally do sort of a pomodoro technique with everything. Breaking it down into smaller parts so I can cover as much space as possible. Cleaning the kitchen turns into two separate tasks (dishes, and cleanup) which I then inject 10 minutes with the wife or kid in between. It probably adds more time to my overall day, but I can't push their schedules later and I need to get work done so I can't push my duties to later either.

The other "trick" is I've never needed a lot of sleep so I can do stuff later at night once everyone is in bed. Sleep on the bus, or whenever I have a free moment.

My previous job was within biking distance so that was my health management. Now I have to ride the commuter bus so I'll have to figure something out once the 2nd kid comes.

Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when setting up your partitions. I keep home and the system separate so that I can easily swap out the OS. Home should be the only location a user has write access.

Having worked with a company that does shady stuff like this I eventually changed how I worked to match it.

I had a boss who thought it would be useful to track line of code changes per developer, number of features implemented and bugs fixed weighted by original estimates and other non-useful metrics to grade employees during their reviews. I was asked to implement the tools to scrape that info.

So what did I do? I used the same metrics and automated my todo list to make sure that I was always in the top 1% of the results. Since I was a lone wolf on a massive multi-year project it wasn't hard to find stuff to do. But when I got to the end of the month and it was trending to show I wouldn't drop a spot my scripts informed me that I was done working. I would also prioritize the level of effort to time left in the month. So if there was only two days left I'd pick up more small tasks to pad my output rather than taking on a bigger task I wouldn't complete in that month.

I started doing this after having been there 10 years. 10 years of me doing other jobs that were not mine "for the good of the company." 10 years of me traveling when travel wasn't part of the job. During this time having great number not much happened with regards to compensation. I went from being a team player to doing just as much as I needed to.

When I finally left and had my exit interview one of my managers noticed my marks were always top 1%...even in months when the company's total output was shitty. Since I was on my own projects there was no reason why I would have had a dip when other divisions dropped. So I asked, "if I had output 30% more than any other group...would you have given me a 30% raise? a 3% raise?" He said, "no we probably wouldn't have done anything beyond the standard cost of living increase."

Remote doesn't always work for every sector of development. I had a huge cubical full of industrial hardware, had a lab with even more hardware, a plant for assembling and testing hardware, etc. We had a "no remote" policy because it just wasn't possible to get things done without actually being in the office.

And after spending years doing embedded systems, industrial control, communications...I was pretty much the opposite of a Web/Mobile developer. Trying to get a remote gig while having none of those skills was difficult (yes there are other industries that can do remote too, but what I was "good at" was not remote friendly tech). I had to create a side job, make a real world project and go around showing that I knew the tech just to get my foot in the door to places that would allow remote work.

I agree. The worst part was one boss was in my office while the other was in the "one hour off" office. The local boss would get annoyed because I'd have to schedule something with the other boss who was already home when I'd get back from lunch. To "fix" the problem I moved my lunch back an hour but eventually that conflicted with local employees' lunch and meetings.

The way the place was run I was expecting one of them to suggest I just skip lunch.

Core hours worked well for me, until one office decided that their core hours would change due to high traffic. Suddenly an office that was only an hour earlier than mine was now leaving just after lunch. I had an office that was 11.5hrs off and we had a great setup where I would do night meetings one week and they would the other. The office an hour off of mine could never get their shit together to schedule meetings.

I worked in an area where the nearest competition was hundreds of miles away. When the engineering staff would question upper management and HR during annual meetings about competitive wages they would always state that we were extremely competitive for our location. After working there for nearly a decade and a half I moved to another state, about 300 miles away and my pay nearly doubled.

Doing my exit interview I stated that the reason I was leaving was because management had this goofy view of the world and it was the reason why we struggled finding talent. They felt that because there was no physical competition in the area they could pay a fraction of what their competitors in the field pay and still retain talent. They also felt that it was appropriate to create a convoluted scheme where you could never really get a promotion, just be given more responsibility w/ almost no increase in pay. (You can only move up a level if you have 1 or fewer "needs improvements" while the managers were told that all employees should have no less than 2 "needs improvements" as they should have things to work on over the coming year).

Most people I talked to about that whole situation would offer the "well why didn't you just move" advice not understanding that the pay was just enough to pay for room and board, college loans, and then choose to put the last few dollars into a 401k or into savings to escape that job. I opted for the former hoping I would work my way up to not have this problem. I made the wrong choice.

It was kinda funny when I showed one of the VP's my setup. He had started the company in the 70's using minicomputers. ed was the editor he used to write code. So when I showed him that I was using it on our system he smiled and then questioned how old I was.

As an example, one I often used for persuasion during sales, we had to dial into a location, which gave us access to a corporate network. From there it would VPN into an offsite office. From there I would connect with point to point radios 10 miles apart to a Gas rig running on solar panels. The radios had huge SNR numbers because they were near other commercial comm systems, high power power lines and were mounted on masts that would sway in the wind.

To load up a 25x80 area would give me all sorts of bad characters. Doing single lines, and find and replace made it almost feel like I was right next to the hardware.

> In a world of increasing automation (explosive in the last 15 years) there's not much value in training for anything less than medicine or engineering.

Yes and no. I think a lot of of this automation will mean we will be going back to the world of trade schools where repair becomes a lot more important. Same goes with installation of these automated systems. The US loves to push "shovel ready" construction jobs but we should be focusing more on training for installation and repair of automation.

I've found it kind of odd that we've lost a lot of the trade skills being taught in high school. I'm in my mid 30's and I'm the only person my age I know who took classes in Small Gas Engines, Carpentry, Electrical, Plumbing, etc. From that point a lot of kids went right on to get Journeymen certs and many now own their own businesses. If they would bring those classes back and also teach these types of skills to those underemployed I think you could easily transition into any type of related field.

I like the diagrams, as many explanations often skip the staging portion of the whole git process. I use that so much that it baffles me that most people skip it. Then again, I typically don't like having tons of "WIP" commits so I stage a lot and if I need to switch to another branch I'll commit a WIP that I quickly `rebase -i` to get back to a clean status.

As for the teaching part, I have found the best results by having you and the learner actually "working" on the project at the same time on your own machines both pushing to a centralized server. It becomes too easy to go over all the commands and feel like you understand it. Most of the scary parts of git are used when its multiple developers on the same project. And oddly enough, having the learner do both Developer A and Developer B's tasks don't seem to work as well as having the learner just do Developer B while I do Developer A. Trying to explain to someone when to use merge, when to rebase, and when to use cherry-picking to get the code I just pushed into their current working branch can be done so much easier when its hands on AND knowing exactly who is doing what steps.

Its not about disincentivizing them, its about not providing them with applicable skills that would make their production worth more than basic hand outs. It can be demoralizing when you realize that flipping burger is worth $100 a week more than doing absolutely nothing, but we don't live in a world where a burger is worth $40 that would allow them to be paid more. Younger people tend to not have a real concept of money and what it really takes to make it.

What needs to be added along with being paid for existing, is training and potential job opportunities to be setup to get them off of the system. I think that most people in these programs would have no issue being given the ability to work. The major issue with be with people who will object to getting jobs they are "too good for." Hopefully those people are few and far between.

For about 15 years I developed control systems for the Oil industry. All of my projects had ed built into their OS for cases when I had to telnet into them to do debugging and maintenance for clients. Most of our other projects relied on FTP as the only way to handle "offsite" file editing which often was too difficult to deal with as these devices lived in some of the most remote locations on earth with some of the crappiest network connections.

This is the reason why all of these "mashup" languages are so pointless.

Everyone feels like X language is so great but if only we could add a feature from Y language to it. They then attempt to trivialize what is needed for that feature not realizing that the benefits of Y are due, in part, to the non-trivial amount of functionality. They almost always turn into a façade of the feature they truly want to support and they never gain traction because their usefulness just really isn't there.

So what are you going to do about it?

I was formally educated to do low level development, did operating systems, hardware design, and communications for a living for 15 years. During that time I also learned and regularly used FP, data processing, windows GUI, full stack web development. Every year I pick a new tooling language so that I'm not completely tied to one language or paradigm. Every time I have an opportunity to use the right language or tool for the job I learn it and use it.

The whole point of my education process was not to learn C and Assembly, it was to motivate me to he constantly learning. When I wanted a new job I created a "real world problem" to solve, did actual design docs, took courses online, read books, etc. Was able to get a new job in a completely different field, doubling my pay and reducing my work load. That's all due to the fact that if I had a list of stuff I didnt know I'd be out there learning that stuff every waking minute.

The issue with Desktops is that motherboard layouts suck. 2' x 2' square with video cards nearly a foot long. Not much room to kill area unless you want fill the random gaps around your video card.

The real place to make things more custom is when you can do small and stick the computer in places it would not normally go. Raspberry pi or a micro atx in the glove box of your car kind of thing.

Except that in-state businesses use services of the state they exist in. Out of state businesses do not, yet they will be required to perform an additional service of collecting taxes for other states because those states have deemed it "too difficult" to do themselves by enforcing a use tax.

So if I got this right SD says the task of collecting taxes from those who reside in their state is not possible for them to do, and unless they honestly think it would cost the vendor $0 to perform this task, they are imposing additional cost of doing business when they provide no services to the out-of-state vendor.

As soon as the vendor is required to collect this tax, and is responsible for it to be paid, I'd consider it the vendor's tax. SD stopped making it the consumer's tax when they lifted the burden on them to pay it. If the vendor doesn't collect it the vendor still owes it because SD says making their citizens pay use tax doesn't work.

When you drive through Ohio you are using services paid by Ohio citizens. The gas you buy had to drive on state roads, cleared of snow by state plows, and sold to you by people who use other state services. Since you don't live there and are just using their services I think it's perfectly reasonable to be taxed.

But what if you never stepped foot in Ohio? What if sent a box in the mail, using the FedEx who charges you money for their services, pays taxes in the states they physically exist, pay for vehicle licenses and property taxes and income tax. All of which comes out of the fee I'm paying them. Has SD gotten enough money from me yet? Still haven't actually used any services that aren't consumed by the one thing I'm doing and paying for, shipping a box

The employees that work in Ohio get to vote, get to have protections by Ohio government, get access to services. The businesses get protections too. And yet I, the vendor, who lives in a completely different state, and never uses a single service of theirs beyond those required to ship a box (odd that there is no extra taxes on sending a letter USPS) is then required to do ohio's job of collecting taxes, and pay any that I miss collecting or am charged a fine. Sounds to me like Ohio is requiring me to fill a job position I did not previously need or else pay a fine. That is all money that now goes to someone else because Ohio says so. Could have sworn that is taxation.

And as for voting rights, I think everyone is disregarding the fact that employees vote. If a referendum came up that would make their job harder or even make it impossible, the employees get to vote on it. Not saying they wouldn't all vote the way the company wants, but their are votes cast for defending their livelihood. Since my company has no physical presence I don't have that same representation. Yet I'm again still required to do everything an in-state business is required. I had none of these issues when my business only existed in the state I live in. And where I and all my employees vote.

Currently the vendor is asked to take sales tax on behalf of the purchaser. If they don't, then the purchaser must pay a use tax. Only that isn't happening. So SD has now put the sole burden on the vendor which means that they are liable if the tax isn't paid. This also means that if your business currently doesn't file sales tax you will have to add that work load to your current business which you didn't have to before. That is an added cost that didn't "have to" exist prior to this ruling. Let's call a spade a spade here, this is a tax on the vendor.

This all sounds like my one man SaaS site now needs to have employees and keep extra book work for states I will never physically be in and who doesn't feel they need to hirden their citizens with actually paying their taxes. That should count for something.

My biggest issue with paying taxes in other states is what services are they providing? You pay federal taxes which covers interstates, you pay taxes on your shipping fees which should cover state roadways.

So if I pay South Dakota sales tax then I should be able to contact state representatives, should be included in votes for any state referendums that affect my business and should basically be considered a citizen of that state. Otherwise I see it as taxation without representation.

I sometimes think people use "availability of devs" to mean "cheap, expendable service". If you're working in an industry where you bank more on hitting the ground running more than retaining developers then this makes sense, and totally valid.

But I've found that lots of places seem to be focused on if you know X rather than being a well versed, developer who enjoys growth. And it feels more and more like the reason is because they don't expect anyone to stay there for more than a few years tops.

I feel like this statement is often used and just as often wrong.

It's not about avoiding the goto like behavior. It's about making you to know it exists and forcing you to handle it.

Rathet than throwing 5 calls deep, doing nothing until you empty your call stack, you must explicitly say "I know I'm part of a system that may error" at each step along the way.

The part you might be missing is that you're explicitly told "this function returns a value OR and error. You must handle error cases with this function". With the try/catch paradigm you never know from the function definition if that is the case.

You also know what type the error will be. No need to derive a new class from `Error` and add custom functions to extract the data from your failure case, just pass the data along.

The real "revelation" of this method of error handling is how it uses types to explicitly state how errors are handled. Having a return type of `Either String Int` let's the user know that this function does in fact have an error case that would potentially be short circuited to a far off error handlers, and that a `String` is the type returned on an error.

In most other languages you either don't know if an exception could be thrown or you just assume every function throws one. Then when you are adding in things like promises which explicitly define success and failure paths the system must implicitly catch all exceptions and pass them to your error path...unless the developer chooses to change that functionality.

Much nicer to have all that defined for you in the type system, even though it existed without it.

When you start looking at the code of the tools, and how older systems were design, it's really is a testament to good engineering practices because it all scales so well. Small, simple, "one task well" utilities that process data in streams means the megabyte files of the 80's and 90's are today's terabytes. Sure they require some work to get things scripted correctly but it really is pretty amazing what coreutils and a shell script can do.