sdevonoes

In Poland in winter it gets dark around 3 PM. Awful. In Spain in winter it gets dark around 5:45 pm. And people wonder why spaniards live longer.

They ask a phone number to sign up. WTF?

I signed up with openai a while ago and I didn’t need to provide any phone number…. I wanna delete my open ai account, but then I cannot use claude without a phone?

In my experience:

1. GitHub. Many times I have found my answer to a problem with a specific library/framework in GitHub issues.

2. Seniority. As I gain more experience, I tend to ask/answer less in SO. From time to time I still read answers.

3. To a lesser extent, chatgpt. I usually have to double check the outputs, but it works fine some times

Interesting! Are you planning to keep recollecting data for the year 2023?

> the major job offer portal in Germany for over one year

I hope that's Linkedin. Because if it's another site like Monster, StepStone or similars, I'm afraid the data is probably garbage. I don't know a single engineer in Germany who uses anything but Linkedin (well, many engineers use niche job boards like remoteok, or directly use the company's career section... but no single one uses Monster/StepStone/Glassdoor, because they are total crap)

Edit: the data source seems to be stepstone.de. That's unfortunate. Is there any chance to run this against Linkedin for 2023? That would be awesome!

(https://github.com/petracarrion/job-market-analytics/commit/...)

Interesting to see many comments regarding "Go is my favourite programming tool, but not my favourite programming language". I totally agree. I love the tooling (go build, go fmt, etc.), the performance, the ecosystem... but the language itself is not the best out there. I would love a mix between Python and Go: Python as the language with Go's tooling. That would be amazing!

So, does your team then spend considerable amount of time writing boilerplate/chore code? Isn't that a sign of: "Hey, we actually need to improve our code base guys!". I don't know, if your solution to "I don't want to write chore code" is "let's use Copilot to do the boring stuff"... well, I have bad news for you: "chore code" needs to be maintained and/or fixed, and I don't think Copilot maintains code (for now... :D)

The most important asset I have is my bank account. In case of death, wife can take over (the only thing needed from wife is to proof she's my wife... so pretty much her ID card and marriage papers). That's it. Subscriptions? GitHub account with private side projects? Digital libraries? HN account? Email? All of that is not that important. If my wife has access to my bank account she can either transfer all of it to hers and effectively cancelling all my subscriptions or reject individual subscriptions manually.

Who's the real target audience of these kind of tools?

- Developers who work at a company (e.g., as employee) and need to spit out features every sprint? Velocity is important, so I imagine these kind of developers need to squeeze every minute they are in front of the screen in order to produce working code?

- Developers who think of written code as one way to solve (tech) problems, so they don't really care much about the process of creating code, but mainly about the output (i.e., does the running program solves the issue at hand?)

- Senior developers who don't like to write boilerplate code?

I don't see myself as the target audience of Copilot or Ghostwriter. I do work as an employee, but I'm not a "feature machine". Usually the hardest part about my job is solving problems while communicating with other people. I don't need to write code "fast", and by the time I hit the keyboard to start coding, I don't really need that much help (granted, I'm not working on code that goes into space rockets... just normal e-commerce stuff)

I like to work on side projects and learn new technologies. When I was starting with programming, as part of the learning I liked to write boilerplate code (actually, that's how I learnt programming. I remember writing C boilerplate code by reading "The C Programming Language". Skipping the "boring" parts wouldn't have helped me in my learning).

If any, Copilot and similar tools take away all the joy of actually writing code (because, when I work on side projects, 50% of the satisfaction comes from actually writing code for the sake of writing code. The other 50% comes from the ability to solve a problem). So, yeah, maybe for the people like me who does find the act of writing code for the sake of writing code (you know like painting or taking photographs), Copilot seems like an unneeded tool?

> In order for her to work on the movie while out, they had plugged the machine up to the local network and copied the whole file tree over.

Now image the same situation in 2022:

- there is no acceptable backup for the whole movie (or let's say, app)

- only you know there is one acceptable copy... but it's on your personal laptop. You did copy it back in the day because, well, let's say you wanted to run the app in our local machine

There is no way you would tell your team/boss: "Hey guys, no worries! I have a perfect copy of it!", because why on earth did you copy work material into your personal laptop?! That's the rule number 1 of every modern tech company: don't mix work stuff with personal laptop (and the other way around: don't use work laptop for personal stuff).

I think we are exaggerating. I started a new position 5 months ago (with a significant raise of around 20% my previous salary). Within these 5 months the company fired a significant portion of their employees (some techies, but mainly non-techies like HR); it made it to HN (not the front-page I think). Hiring freeze for around 3 months... but since about a month ago they started to hire again. Now on Linkedin you can see the company is posting around 200 job offers... although, sure before the lay-off they had like around 1000 job offers (crazy).

My point is: if you go to Linkedin right now and filter by location=Europe, remote=yes, you get like 160K job offers (tech ones). Sure, you can filter down that number by removing managerial positions and other roles you are not interested in, but the thing is companies are still hiring (not all of them, but the majority).

Maybe it's just Europe? I have no idea about US.

Product developer (or Product Engineer since we use the word engineer everywhere). Compare team A = {software engineer, product engineer, design engineer, qa engineer}, and team B = { software engineer, product manager, design engineer, qa engineer }. Team A screams "all team members collaborate the same way when it comes to build a product". Team B screams "there is 1 manager, and the rest are not"

You let your engineers diffuse the "Why".

You let your engineers figure out the "How".

You let your engineers implement the "What".

... at the end you let your engineers figure out everything. So tiring.

Try quitting HN. If you are able to stop the urge to reply my message, then you are on a good path.

Another problem is that it's not programmatic (e.g., like Vagrant), so it's tiresome to spin up/down a bunch of VMs.

I use debuggers, but only if "prints" don't help me figure out the issue at hand first. Debugging via "prints" works out of the box.

You put a "print" statement dumping whatever data structure you want, you run the program again, and voila you got something. Now, the "where to put the print" is an art on itself of course. If you don't know where to put it, then either you start writing multiple "print"s here and there (following an approach similar to binary search) or you use a debugger and go step by step until you find right place to inspect.

The problem with debuggers is that they do not work out of the box. If you use the terminal, then you have use an external program and read its manual to understand how to debug, how to put breaks. Depending on the platform you are using, you may require even an executable to run the debugger on. Sometimes you don't have an executable. Sometimes you don't know where the "entry" point of your program is, but you know where the bug relies. Some debuggers require you to point the debugger to the entry point.

If you use an IDE like Jetbrains', then for debugging you need as well to do some (minimal) setup as well (the last week I had to debug a Node.js program: it was simple, but it didn't work out of the box. Also, when I open my IDE on a different Node.js repository, my debugging setup was gone).

The first time I encounter TDD, I was a bit surprised because it encourages you to write tests (client code) first. Well, I started my professional career without knowing about TDD, but I did know that usually it's best to start writing the client code first. E.g., you write your main.c/Main.java/main.go first, referencing classes/code that do not exist yet, and wiring everything together. Then you move on to the next layer, write code that should exist but still relying on future code that doesn't exist yet. Eventually you end up writing the whole thing. Sometimes the other approach works equally well (e.g., starting from the small blocks and going up).

But TDD (the main topic being discussed here) has nothing to do with that, right? I mean, how on earth is TDD going to help you decide between a) using a simple data structure like a collection and b) a more sophisticated data structure like the adjacency list, if you have no idea what an adjacency list is?

Exactly. I write my programs/systems a few times. Each time I discard the previous version and start from scratch. I end up writing code that's easy to test and easy to swap parts if needed. I also know what TDD brings to the table. On top of that I have over 15 years of professional experience... so I usually know how to write software that complies with what we usually call "good code", so TDD offers me zero help.

For more junior engineers, I think TDD can help, but once you "master" TDD, you can throw it out of the window: "clean code" will come out naturally without having to write tests first.

The infrastructure setup. You have an idea, you can program it... but you need all the incidental complexity that goes with it is a headache for me:

- server(s) setup (either on prem or cloud)

- keeping the server secure

- auth

- logs

- monitoring

- backups

- HA/scalability

It's even worse if you don't like such topics.

I got like 1 or 2 per year.

They are learning "best practices" from the best (Google and others), I imagine.

- Terraform to spin up VMs in the cloud (e.g., "give me a Ubuntu machine with 4GB of ram")

- Ansible to provision such VMs

- Docker to start/stop containers on such VMs

It feels like a breeze of fresh air!

As someone who has read perhaps 75% of the books listed there, the outcome I got is: you need to learn the rules only to be able to discard them. Plenty of the "principles", "patterns", "laws", "good practices" that abound in these books are not only irrelevant but dangerous in plenty of real-world scenarios. From introducing an hierarchy of abstractions soon in the project, to apply blindly Brook's law, to using Scrum all the time... The real deal is to be able to say: "I know that most of you guys will say 'Let's apply Pattern X to this problem!', and while M. Fowler would also agree, based on similar projects we have done in the past, we definitely should not use Pattern X".

There is nothing more dangerous than an engineer that after having read all these books, is incapable of accept that sometimes following M. Fowler is the wrong path to solve that little problem we have at hand.

I just joined a new company fully remote. Been working in a fully remote company during COVID. I receive offers in Linkedin where 70% of them are fully remote and the rest are hybrid (I don't receive offers which are 100% on site. Funny). So, I think fully remote is winning so far. This in Europe.

Depends. Sometimes it's easier to tear down everything and start from scratch.

I have a bachelor and master degree in computer science. I have worked for over 10 years in the industry. I keep learning (and re-learning) every week.

> My tentative plan is to get a part time job, and then spend 6 months reading books, learning tech I’ve always wanted to learn, and hacking on at least one build-your-own [2] type project.

Sounds good. Get a job, earn some money and focus on your long-term career. Start with the fundamental concepts (e.g., operating systems/networking) and complement it with more modern applications of such concepts (e.g., containers, distributed systems) at work if possible otherwise at home.

Thanks. I didn't know that.

> The key here is no building (packing, bundling, transpiling).

How is that possible? In the documentation (https://fresh.deno.dev/docs/getting-started/create-a-route) I see .tsx files... so I imagine that at least one needs to compile TS to JS and then JSX to JS. Perhaps I got that wrong, though and browsers nowadays support TSX out of the box.

> except you can write code like it's not the old days.

I imagine you mean that writing (frontend) code now a days is better than how it was in the old days. Well, at least from my perspective that's not the case. "Modern" frontend code requires:

- a package manager (npm)

- node (or deno or whatever)

- transpilers (or is it plugins?)

- TS

- 10K+ dependencies

And to be honest, what is all that good for? To being able to "hydrate" some server-side rendered template? Not good enough reason.

Interesting. Do you scrape LinkedIn or do they offer some form of API to gather number of jobs published in the last X hours/days/etc. ?