kugurerdem

> With each Android update, I notice reduced control. Many background services and unnecessary system apps increasingly have immutable permissions. And permissions... This seems more convoluted and crippled with every update.

Maybe the best way to get rid of bloatware in our phones is simply not to use phones at all. :D

On a serious note, do you think there are any promising alternatives with less bloat to Android? I'm asking because I'm open to trying some alternatives once I'm finished with this phone.

> Android is pretty sleazy. But I suppose the bulk of the tech paradigm is too.

Well said, only some of us who are really dedicated can avoid such complexities, to a certain extent. Otherwise, we are sucked into these bloated tech paradigms anyways. Its a bit depressing.

> Be careful with Xiaomi MIUI Android phones removing security manager related apks (that run apparently as root/system) can break the phone and you need to reset via fastboot or so - Learned it the hard way.

Good point. I specifically avoided removing anything that I didn't understand its function or wasn't sure if it could be deleted. Perhaps I should include your point as a warning in the essay as well.

> However the gallery app still uploads to Xiaomi servers without consent for some filters - overall it's my last Xiaomi. Lineage might work fine but I wanted to avoid all the complications of unlocking bootloader.

This is prolly my last Xiaomi as well. Are there any phones you're considering switching to next?

> What has your experience been in starting a tech blog?

I published my first blog post about a year ago and within the last year, I've written around eight essays in total. Most of them didn't receive much interest, with only a few of my friends reading them. However, two of my blog posts managed to make it to the front pages of HN.

One problem I encountered when starting a blog was designing my site. I knew that if I aimed for a very aesthetic website, the design and development process would consume most of my time, potentially preventing me from publishing any posts and resulting in a state where I give. So, instead of aiming for the best UI and such, I initially preferred my blog to be functional and easy to maintain. This decision led me to come up with a simple blog where, initially, the only things on my blog were the posts. I have built my blog using Hugo, a very simple static site generator that provides almost all the essential tools you might need for blogging.

I believe my essay writing skills have significantly improved since I first began. If you're not a natural born writer, it's most probable that your first attempts at essay writing won't be perfect. But, the key to better writing is practice. Which means you have to be prepared to write some imperfect essays to improve.

Just remember, your progress could be hindered by perfectionism if it stops you from writing out of fear of not living up to your own high standards.

> I want to start one as a way to explore and express my interests, which currently include HTMX, Django, Python, and data engineering. I am afraid of sharing though and getting negative feedback.

I recommend that you just go for it. I would not worry about any negative feedback as long as I try to respect people's boundaries, stay humble, and avoid making baseless claims. That being said, bear in mind that some people might try to discourage you, no matter how good your work is. For those cases, just keep in mind that the problem is most likely not your work being bad but them being a negative person.

Feedback can either be helpful (providing possible improvements for your writing), or it can be unhelpful (and even contain demotivating phrases). At times, it can be both. Focus on the helpful aspects of the feedback and ignore the unhelpful ones. If someone takes the time to give feedback on your content, it's often a sign that they see the topic worthy of giving time.

> Was that something that you pushed through when starting?

It is not something that I pushed through.

I often find myself explaining topics I'm interested in to my friends. I thought it would be great to write my thoughts and experiences on some of these important topics, so I could easily share them with my friends. I also find myself writing things down primarily for myself for solidifying my thoughts and providing guidance for later.

I already had enough reasons to write before starting to write publicly, I just realized that I could easily make these writings public with just a little effort. So writing a blog is more of a hobby of mine than a task. I won't write if I don't have the time for it. It's not something that exhausts me, as long as I don't do it with big expectations.

> Did starting a blog lead to a new job?

To give it a short answer, no. At least, not yet.

It's not really a problem nor is it something I aim to achieve through blogging though. If your ultimate goal is to secure a new job, it would probably be more beneficial to explore other alternatives.

The author differentiates between knowledge that is lasting (non-perishable) and knowledge that is trivial or temporary (perishable). He uses this distinction to explain his preference for enduring technologies or philosophies like UNIX or Vim.

I personally agree with his point. And this is how I also approach learning new things. This also provides an argument for why we should choose boring technology [1] over the exciting ones.

[1] https://mcfunley.com/choose-boring-technology

mermaid.js seems interesting. It reminded me of Graphviz. Another tool I have used on my environment.

> Knowing that people read the stuff I write is the only motivation I have for writing at all. If all my posts are seen only by bots, then the hours I spend making them are pointless.

For me, it varies. If my aim is to make an impact around me, then the more traffic there is, the better. However, sometimes just clarifying my own thoughts is a good enough reason for writing. Anything beyond that is a positive side effect.

This was a nice and short essay.

I think that it can be hugely motivating to see your essays reaching people. However, as the author pointed out, it can also be demoralizing if the ratings are lower than expected.

With that in mind, I don't think we should stop traffic analysis. The issue seems to lie in our initial expectations. I plan to apply some analytics, but I don't necessarily anticipate high ratings.

Also the author probably isn't advising us to completely discard analytics. He actually provides us with a simplified method for it. I think what he tries to do is to suggesting that we should not obsess over it too much. I agree that if analytics demotivate us from writing, it might be best to completely remove it.

I just read the essay and found the examples given interesting. I certainly believe there are valuable lessons to be learned from them. However, I don't think the content fully supports the claim made in the title.

It seems that the author's focus is on how things can become needlessly complicated, even when trying to implement a seemingly simple feature. However, citing only a few examples is not sufficient evidence. Could we not also consider instances where writing additional code could actually help reducing long-term technical costs?

Aside from this, I found the following points interesting:

> A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones.

> Even when it becomes apparent after the fact that the feature isn’t performing as well as we anticipated, the typical approach is to do nothing. Part of this is the sunk cost fallacy. Often there is the hope that even if the feature isn’t used today, it will be in the future. But there’s also a legitimate reason for doing nothing. Removing a feature also has a cost, both in the development effort needed to cleanly remove it, and in potentially upsetting customers. So once a feature is added to a product, it is almost always there to stay.

> People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer.

I think this point extends beyond the idea of guarding ourselves while reading the contents of good writers; it's also about how we should approach our jobs. Being a good writer will most likely improve your skills in dealing with other people. As software developers, writing and communicating with others is crucial to our work.

I would also recommend beginners to write about the challenges they have encountered, their experiments, and their thought processes, among other things. If possible, they should write essays. This will prove to be a really useful skill later in their careers.

I've just written an essay about how I integrated AI tools like ChatGPT and Copilot into my terminal workflow, the problems I faced and the solutions I found.

I would also appreciate hearing your thoughts and learning about your own workflow.

I found this essay to be quite impressive.

I can personally relate to the impact of utilizing LLMs in order to overcome the Intermediate Material Problem discussed in the essay. Whenever I inquire LLMs about my current situation, I often discover the key concepts I may be missing. Admittedly, the quality of the responses depend upon the quality of the prompts provided, but this holds true for any other platform that one may use for seeking answers to their questions.

I didn't know that, that's a really cool information. Thank you! :)

But what do you use to insert tabs then? For me, giving up Caps Lock would be a lot more convenient than giving up Tab, because I almost never use Caps Lock, whereas I use Tab a lot.

These are great references. Read them all briefly, without getting too bogged down in the technical details. As far as I understand it, the libevdev library basically provides one of the lowest levels of interaction with evdev files that comes after reading them yourself, and it is not recommended to read evdev files yourself, as there are many intricacies that can occur.

I have just read your README.md file and found your repo interesting indeed. The README is well written. I knew it was possible to read and parse /dev/input/* files, but was hesitant to get into the intricacies you described.

Anyway, great job sir! Now I will read your code out of curiosity :)

I've just finished writing an essay where I talk about my recent experiments with X and managing keyboard events. If you've had similar experiences or have any thoughts to share that could help clarify things even more, I'd really like to hear your thoughts.

I think 84 WPM is very sufficient. I am curious, what was your WPM at the start? What things you have done in order to improve your typing speed?

Hello! I noticed your message and responded accordingly.

Also, I've taken you saying "couldn't find a way to contact you" to heart and decided to include an email contact address on my blog. Thank you! :)

While I maintain a continuing interest in Computer Science, you are correct. The essay isn't explicitly focused on Computer Science but more specifically Software Development. I'll fix the title based on your recommendation.

Thanks Andrew,

> It's always fun to read someone else who also had a lifelong interest in programming but decided to major in a different subject.

I feel the same way; I enjoy hearing the experiences of software developers who pursued different majors or didn't major at all. Based on my personal experience, individuals from such backgrounds often bring a unique and intriguing perspective. They also tend to be highly self-driven, perhaps because those who lack this self-motivation may struggle to sustain their careers in this rapidly evolving field.

> later Haskell got me good enough into abstract algebra that I tacked on a math minor as well.

For me, it was the other way around. My interest in pure math led me into learning more about Haskell and functional programming stuff.

> I often worry whether the EE degree disqualifies me in the eyes of employers from being a "serious" programmer.

I don't think it matters significantly. Electrical Engineering is so fundamental that it will actually provide you with a strong foundation and valuable problem-solving skills in the software development field. If your employer does not see the value in you, its their problem.

> I'm mildly surprised that the Turkish university scene sounds tougher to break into the top university ranks of, than the United States's was. I wonder why that is the case.

Regarding the Turkish university scene, it's interesting to hear that it might be tougher to secure a spot in top-ranked universities here compared to the United States, *but I don't know whether this is the case*. The central exam system in Turkey, leads to varying demand for different degrees. Perhaps a more intriguing question is why engineering programs in Turkey seem to have exceptionally high scores in this context, that is, why the people in Turkey particularly tend to choose engineering programs such as CS or EE degrees.

Just a blog essay where I reflect on my CS journey when I am now in my mid-developer phase.