I tried eM Client for last week.. and, nope. Not my thing.
- Cannot select which email to look at "next" after a delete
- Does not display number of item in the current mailbox (like Postbox did)
- Lack of a Unified set of folders.
- Unclear what mailbox any given item is in. Cannot really figure this out, when looking at search results, for example. Just not clear
- It looks like a tool written for Windows, ported to Mac. There is a reason I switch to Mac, that's just one of them.
- I could not figure out how to control where 'sent' emails go.. I'm picky
- Cannot 'group' email accounts.
I mean, it isn't "Horrible", but I'm not feeling it. I'll continue to use Postbox for now, and be searching for an alternative. I already have a paid copy of Spark -- but never really loved that either (but there is a Phone app..)
When did software engineers adopt this "cheapest is best" strategy?
- Only use free ides
- Cheapest computers
- Get it free, blah blah
I'm a Software professional - most reading this are also. We get paid pretty well in general.
I don't compromise on my tools, my hardware, my monitors, etc. I buy software tools that make me happy, better IDE's, licenses to tools I find useful, etc.
This mindset that a "good" software engineer should be a cheap bastard is insane to me. I respect my craft such that I'm willing to pay OTHERS that develop good software, and good hardware. I buy the most expensive computer I can afford. Period. You want to get by on some old boat anchor? You have something to prove? Fuck you. You don't respect yourself.
My Macbook pro has the fastest 4TB SSD you'll ever see.
I use about half of it.. so what. I get no brownie points for "using all of my disk" More is better.
I can run dozens of apps simultaneously -- I have so many apps running I can't count them.
I rarely reboot -- get annoyed when I have to.
I could probably "get by' with less of a machine, but fuck that. I live my laptop, and I can run 4 full screen large format monitors with it.
Have some self respect. You are a professional, buy yourself professional tools. Nobody gives a shit that you are some cheapskate that "gets by" with less.
I heard a saying recently that went along the lines of "engineering without constraints isn't engineering", and after reading "The Performance Inequality Gap"[0] and its follow-up series "Reckoning"[1], I'm convinced that software developers should use lower end devices so that they, too, feel the pain they're inflicting on others.
Running cheap hardware is fun and will make you want to improve your craft.
You should be testing your software on the typical device it will run on. It's just good engineering to do so. If you have to eBay a bog-standard laptop to do this, do it.
Developing software on the average potato device? Hell no. What a waste of time.
> I buy software tools that make me happy, better IDE's, licenses to tools I find useful, etc.
I don't use free software because it's cheap, but because it is free. Anyone trying to make a profit on the tools I depend on will eventually screw me over by capitalizing on that dependency or leave me in the lurch by abandoning the business. Tools maintained by and for the community which uses them are the only tools I can trust.
> Nobody gives a shit that you are some cheapskate that "gets by" with less.
Oh, but I certainly do - and, like most of us, I care far more about my own opinion of myself than I do about yours. It feels good to get by with less; it suits my aesthetic. Self-imposed constraints are almost as interesting as external ones, and discipline sharpens my skill.
> I buy software tools that make me happy, better IDE's, licenses to tools I find useful, etc.
So do I. But, for my use cases, having a top-of-the-line machine doesn't make me happier or a better dev. Why should I spend money where it isn't going to get me anything I value?
> You have something to prove?
No, I don't. Which is another reason why I'm not drawn to having the most powerful equipment possible.
> Fuck you. You don't respect yourself.
You seem unreasonably angry by the choices others make that don't even affect you.
"Software professionals" are precisely the people who should be forced to use the cheapest computers available 10 years ago!
Hell, we already had graphical OSes back in the 90s, when RAM was about the same size that is now L3 cache, swapping to hard drives the size of today's RAM. And of course each disk access was audible, so that you could tell when the computer was working hard. Imagine a little clicking noise on every cache miss today!
To a large extent, it's the absolutely moronic code banged out by "professionals", with its dependence on libraries upon libraries, JSON or XML encoded everything (because binary formats = scary! can't manipulate them with regular expressions!), that is responsible for modern software taking noticeable time to react to a simple key press, even when running on a CPU that can do dozens of 64-bit operations in the time it takes light to travel from the monitor to your eyes.
That said, I would agree that the article isn't very good, it contains a lot of conspiracy mongering and 4chan-like language.
Interesting points, all.
But - you don't need to run an old machine to test software.
If you are writing mobile apps, then your dev machine is irrelevant, get the best one you can.
Writing web apps or Native apps?. Run a VM or other fine test options.
> Running cheap hardware is fun and will make you want to improve your craft
I see nothing fun about that, to be honest. We must agree to disagree here.
As far as Improving my craft? Disagree strongly. Improving my craft means learning the technologies better, mastering new technology (AI, LLMS), and writing code. Has nothing to do with being on a crappy machine.
> Anyone trying to make a profit on the tools I depend on will eventually screw me over by capitalizing on that dependency or leave me in the lurch by abandoning the business
Sounds like someone has been burned before. I do agree that using JetBrains software (my personal favorite) does make you somewhat dependent.. But, if JB died tomorrow, I'd find the 'next best' thing.. I would adapt. The "possibility" that JB might die does not make me want to NOT improve my daily work life..
> Oh, but I certainly do - and, like most of us, I care far more about my own opinion of myself than I do about yours. It feels good to get by with less; it suits my aesthetic. Self-imposed constraints are almost as interesting as external ones, and discipline sharpens my skill.
This is the unreconcilable different part. It always surprises me that some people just "like" the challenge (or whatever) to get by with the lowest possible hardware.. but, it is obvious that some just love that. I just love having a nice machine and environment.
I get this is the same motivation that drives someone to get a really "nice" car, and others to drive an old beater cause "it gets you where you are going just as well as that Mercedes, Lexus, etc...
> You seem unreasonably angry by the choices others make that don't even affect you.
Yeah, that's on my. Sorry for the angst. I'm not really as angry as I sound. I apologize for the tone. We all have our preferences, I need to respect those of others as well.
What Chat system are you using?
- "one line at a time" -- what?? No chat system I use works like this. You get a paragraph, even a whole page, with notes, images, etc.. all at once.
- 'must constantly watch the channel' -- what? No you do not have to do this. Mark yourself as away, and get back to the Slack (etc.) conversation later.
It's a nice article on balance, but you definitely have some "contrive" negatives there.
- "Implied consensus" again, wrong. I mean, it's possible that "some people" might discuss a topic and then go off and do it, but generally, anything that requires "consensus" would be left until.. there was consensus. That's an easy one to fix.
- 'Knew Jerk Response' - again, complete bollucks. Nothing "scrolls away", you have a huge or infinite history, and the tools show what has not be read, so just read it when you have time. I've never been in a conversation where there is some "urgency" to read this right away and respond.. who are you talking to??
Item 7 - Yeah, I can see that one occasionally, but not the people I generally work with. On "shared internet" channels, yeah, but internal work channels.. almost never.
Some of the other items seem more real, and things I've experienced. Some seem like minor, nit-picky things though. 25 used to be 1... yeah, occasionally a conversation can drag on --- but so can an email chain.. and, don't get me started about how many "Meetings" ramble on long after the main point has been (or should have been) made.
Some key points I might make -- it's better t have many smaller conversations, with specific individuals, rather than "a small number" of truly "pile on everyone in the organization is in this channel" conversations. Maybe you need to better organize the groups of people in a particular discussion?? Just a thought.
Item 14 -- it's called search, and yeah, it works really well. It might be a great "long term reference" but then, is email? is a meeting? Is a zoom call (or equiv)? I mean, if you need something for long term -- document it for pete's sake (sorry Pete).
#15 - Yeah, that does happen..
#16 - this can be true, but, I don't hesitate to just ignore something I have to. maybe that's a "company policy" that can be implemented?? Maybe not..
My key point here would be - While Chat "seems" like it should be immediate, it is also possible to treat it as "asynchronous", where an answer is NOT required immediately. You have some good points, but I think you "stretch" the negatives to sell your overall point just a bit too much.
I use Tabnine - https://www.tabnine.com/
It supports multiple LLM's and it has it's own internal one, and it can be secure for a company and their codebase, unlike the generic OpenAI, Claude, etc.
I do have OpenAI keys and Claude, and I use them both (just as the mood fits, to see which works best).
I'm been coding for decades, so I"m quite experienced. I find that an LLM is no substitute for experience, but it definitely helps with progress. I work regularly in a range of languages: Java, Javascript with Typescript, Javascript pure ESM, Python, SQL. It's great to have a quick prototype tool.
One key takeaway - learning to "drive the LLM" is a skill by itself. I find that some people are "hesitant" to learn this, and they usually complain about how bad the LLM is at generating code.. but, in reality, they are bad at "driving" the LLM.
If I put you in an F1 car, the car would perform perfectly, but unless you had the skills to handle the car, you will not win any races.. might not get around the track one time..
Also, I'm in my 60's so, this is all "new" tech. I've just never been afraid of "new" tech. I'd hate for some 30 year old hot-shot to show my up because they learned to master using that LLM Tool and I just blew it off as "new tech".
I train my team on how to resolve this. Every team member is able to resolve a force push onto a branch they have local.
Also, we tend to avoid having multiple people work on the same branch.. so, that's also a thing.
If there was a multi-person development effort, then each of those people would have to have a sub-branch of a main feature, and then they would be rebasing their work onto the 'main' feature branch.. which would ultimately be rebased on to dev.. etc.
I take all "WIP" branches and rebase them as needed onto the 'latest' development. Any continued work on those branches will have to be compatible with all released code, so deal with any issues -- i.e. merge issues during a rebase -- now, rather than later when you try and submit a PR.
As a team leader, I prefer to avoid "a lot of" WIP branches, but I just expect developers to rebase their WIP onto dev, etc.
Oh, and I really really dislike "merging" develop into the WIP branch. This accomplishes the same thing as "rebasing" the WIP branch onto develop, but it leaves a horrible mess behind.
Frankly, I don' give a hoot about some "history" of work. In the end, I care about the unit of work encapsulated in that WIP branch, and that unit must always add on top of develop. Rebase just makes that super clear.
Estimated annual sales of iPhones in EU are about 12.4M phones in Q4 2023. If you just do quick math, that is 49.6M phones/year. If you pick an ASP of $800 (??) then that would be about $39.7B annual Gross sales.
If EU actually tried to get that money, Apple would have to just halt all sales of iPhones in EU.
Now, maybe that's what the EU really wants. Are there some bitter former Nokia execs on the EU panel?????
If Apple halts their iPhone sales in the EU, they endanger their platform globally. Because suddenly a pretty large and important market would go 100% to Android. Also, Macs would become extinct pretty quickly in the EU.
The fine initially would be up to 10% of the revenue. I don't see how that is outrageous if the violation of the law is there. The actual fine could be lower, but on the other side, the fine needs to be high enough that it can force the fined company to stop breaking the law.
I'm sorry that you have such an emotional reaction about a company being threatened with a fine (not even penalised yet) for harmful behaviour which they could immediately choose to stop if they'd want to.
*
Two scenarios:
Company A violates consumer rights. Government does nothing, consumers continue to get ripped off.
Company B violates consumer rights. Government threatens fines. Company either fixes the problem (consumer hsrm reduced) or eats the fine (and the money can be used to pay for useful stuff). Either way, they can no longer gain by tipping off consumers and have every reason to stop if the fine may be repeated for a repeat offender.
*
Calculating on global profits is standard practice and is done the same theme the US calculates fines (depending on what the fine is about - you might have different reference points for different harm). This is the only solution as otherwise companies will play the usual whack-a-mole where they create an "affiliate Europe" that is legally separate but pays 100% of its net profits as a licensing fee for the brand name to the parent company, thus making 0€ (more difficult to play this game with gross sales, but there are still plenty of ways to fudge those numbers).
Bruce Schneier recommends cigarette rolling papers
> Burning is probably the best method of data destruction available, but think about the paper. Ungummed, rice cigarette papers seem ideally suited to this role. A colleague did some tests with Club Cabaret Width papers, and they burn completely.
> It’s not as difficult to write on cigarette papers as you might think. Using a No. 2 pencil with a fine but blunt tip works well. A No. 3 pencil works better, but it is a bit weirder to be carrying. Pens have a number of problems. First the extremely hard tip of the pen is more likely to leave impressions in the surface below the paper. Also, anything with ink has the possibility to bleed through to the surface below.
> And good cigarette papers are made to burn cleanly and completely. The Club papers burned best when allowed to burn in the free air. That is, lit and released at about chest level. These papers also have the advantage of having very low volume and could be easily eaten if required.
I use git rebase all of the time.
We rebase all features onto develop.
Develop is then merged --ff-only into stage/release, etc.
Which is then merged --ff-only into main/master, and then tagged.
I use squash less, as it can be helpful for blame of course, so rebase with minimal squash (like, squash that typo fix).
The article makes it sound like a 'rebase' workflow is so complex, and time consuming. Poppycock. it's easy, and force pushing a branch cause practically zero issues for developers.
If I have to rebase develop, for example, and then force push it, then remote users only have to do this:
git checkout develop
git reset --hard origin/develop
Since a user would never have any local changes in develop, it would never be an issue.
The "fanaticism" about and against rebasing is overblown in my opinion.
Oh, and the "time wasted" dealing with merge issues.. same, exactly the same in fact.
Granted, I don't go around rebasing everything all of the time, but a developer working on a feature just rebases to develop before they submit a PR. Sure, if there are multiple PR's then they also need a rebase merge, but since nobody would "continue" working on a feature once it is submitted, this isn't an issue.
Oh, and IF they did, well, again, they can just pull develop and rebase their feature.
Now, what I don't do is have multiple developers on a single feature branch. If my team was much larger, and that was a "normal process" then, it may well make rebasing more of an issue..
Maybe you've only worked with average to good devs who communicate well, like I do now, but I guarantee that in our field, we have people who can at the same time be bad to average AND bad communicators (or worse, toxic liars).
Luckily, now our worse communicator is also our most competent dev, but I've been in teams where learning basic git would be a month long challenge for half the people, and for half of those (two people, really, we were 9) communicating their difficulties, or worse, their mistakes was impossible.
I mean, it isn't "Horrible", but I'm not feeling it. I'll continue to use Postbox for now, and be searching for an alternative. I already have a paid copy of Spark -- but never really loved that either (but there is a Phone app..)
The search shall go on.