skysight-inc/HackerNews huggingface dataset:
It's not clear from your post (and you don't have to make it clear, of course) whether you're getting fired from your current company or not.

Merely failing one task won't get you fired and if you have the self-awareness demonstrated above to realize that you haven't yet learned what you need to become senior, gives you a clear path (and one that won't even be that hard if you've been selling and making software for 10 years).

Making software in a team is a somewhat different skill and you just need to learn it.

I contrast your case (understanding the issues) with a code review I did around 20 years ago where someone had hardcoded the value 17 in a bunch of places in a mixed c / c++ codebase. I suggested he use a #define for the magic/hardcoded values.

I kid you not, his resubmission contained:

#define SEVENTEEN 17

and the points of use all now said SEVENTEEN. (At least the instances of 34 were replaced with SEVENTEEN * 2.)

That programmer wasn't going to make senior. You will. If you're getting code reviews that are pointing out these issues at your current place, stay there and learn. 6 months from now, you'll look back at your thread here and realize just how much you've progressed with the live mentoring in a team and the spaced-repetition of go away and code, get review, improve it, get review, etc.
So, rather than using the traditional device-independant units, we should use another device-independant unit that pretends to be device-dependant, but isn't?
One word: Epistemology

Having been at this for over twenty years. The one distinguishing factor I've found between the great and the good, is their personal epistemological process; How they seek out, evaluate, and incorporate new knowledge, then transfer that knowledge into skills. The good ones have a great process for this, and they do it constantly.

Mad props for recognizing your problem, there is a solution, and it is the thing to which other posters have mentioned. I was in your same position about 7 years into my career. I went from a small town, in jobs with 1 or 2 engineers, to a major city with thousands of very talented engineers. I nearly drowned at first, but I rose to the challenge and adapted and you can to. Every day will be like drinking from the firehose for a while.

You should be learning. Constantly.

Being in small shops, you likely suffered from the fact that your work was not being challenged, and therefor you were not being challenged. It is easy to get comfortable and to stop learning and growing in this state.

When you are frequently challenged, you have to seek out new ideas, algorithms, techniques, languages. This all adds to your knowledge base and skill set.
always nice to have the data to confirm the hypothesis.
> When you take into account the typically high click-through rate, Google is making more on a CPM basis(per 1000 pageviews)

Is this your direct experience? In my campaigns it's typical for me to see 5% CTR for the keywords I target and then a ~30% CTR for branded terms (depending on the brand name)

Branded clicks are more than 6x cheaper than non branded so the CPM is still lower.

Again, that at least has been my experience. And regarding the "would have been free" argument, I've gone back and forth and have seen better results with branded campaigns than not having them on. But I've seen accounts where that was not true.
This is why Governments shouldn't be allowed to force these sort of things. Governments can be and often are wrong.

Also add to this potential influence by malicious actors.
I think we have the tech, we are just bad at figuring out how much it would be worth to spend (underestimating the value by a lot).
While I disagree, I have to admit there are tidbits of truth here.
Actually I deeply envy windows users. They can enter a computer store and basically choose any hardware with the certainty that it will very likely work on their computer; then can sign any on-line service with the same certainty, they can use almost any recently released professional software with the same certainty...

Linux on the desktop is MUCH better now, it is improving but still no there yet. And I've been saying this very same phrase for decades now.

I don't care about a significant fraction of the desktop, but I'd love to enter a computer store and choose a hardware without severely limiting my choices.
Yes, it's the system, not the people. Same why laws matter and not corporations "playing nice".
What has really ruined my trust for Boeing is not necessarily the incidents with the 737 MAX model specifically, but more the change in that company's culture that these incidents have made me aware of. I can recommend this video[1], but the short of it seems to be that Boeing over a period of decades has replaced its previous "engineering first" culture with what I can only describe, for lack of better wording, as the "suits taking over", with predictable results.

[1]: https://www.youtube.com/watch?v=y_zn_x2JK5Q
Don't become a project manager.

If anything become a product manager. It is a desperate need to have product managers that have some inkling of what it's like to develop software. In some places this might be a semantic difference, but project managers seem more about people and scheduling than understanding a software product. Your background will be more useful a bit closer to the code.

If you are interested in continuing to build software: everybody sucks.

Difference is: some realize it and some don't. You are a rare person that made the jump over the chasm.

We all take shortcuts. We all compromise. And none of us knows enough to have the perfect solution pouring from our fingertips at any given time.

Guess what? Those things you've identified? Yeah. Bad. But even after you fix all of those, there are hundreds, maybe thousands more waiting for you to identify them and fix them.

And when you fix enough of them you'll realize that striving to code perfectly is, itself, a code smell.

And you'll start doing some things 'wrong' on purpose. Why? Because it's all a trade off. And you're not coding to code, you're coding to solve a problem. And sometimes that problem doesn't need perfect code to be solved.

All of that 'bad' code you've created? It solved a problem. It's probably not as bad as you think, given the parameters of the problems you were solving.

By all means, fix the problems you see. Try to do better. Learn from others. Rinse and repeat.

You have to enjoy that journey because it should last a lifetime.

And if you don't, there's always product management.
Sorry, by mistake I replied to a wrong comment — I meant Input, of course.
> for example much of eastern Europe and Turkey has authoritarian rulers, also see all these censorship rules on twitter and faceboook

Hungary is usually considered Central Europe, and they're the only ones i can think of besides Poland and Belarus. Maybe Serbia if you're being generous?

That's far from "much of Eastern Europe ( there are 10 countries in the Balkans only).
Please don't do this. Substantial comments are much appreciated.
Honestly, in most of my experience the higher the title of the developer, the worse the code is. Developers aren't promoted for writing nice code, they are promoted for getting projects out the door, on time. This usually requires sacrifices in terms of engineering.

I'm in a pretty similar situation: I'm reasonably adept at coding challenges, but fall down when it comes to developing more complicated applications. I've found that I'm most useful on teams with good tech leadership. Every medium+ size team has unglamorous, easy work that just needs to be done by someone. So I'd suggest keep moving jobs until you find such a team, then stick it out.

Also -- and this is going to sound terrible -- but at a large enough company, you can be incompetent and still collect a paycheck. You'll probably be given busy work or tasks that the managers understand aren't going anywhere. And realize that 50% of profits from companies are generated by sqrt(total_employees), meaning, that, in general almost nobody is a big money maker.
You are right, I was quick to judge without knowing. Thanks.
Input is a really great font; sadly, not open source, so cannot be shipped by your favourite distro.
> But yeah, show it to a c# newbie who is used to e.g. Python where "Hello world" is literally a one-liner and they might think "what a crapsack language, there's like 6 lines of overhead per 1 line of code, argh this is as bad as Java" - I've seen pretty much this reaction. Is it justified? From my POV, not at all. But I have seen that happen.

I don't understand why we keep optimising for this audience in the first place.

These are people that lack basic understanding, but also have no patience whatsoever, or any intentions to RTFM. Why are we bending the ecosystem for this audience?
When the doctor's office is inundated with patient visits, you cannot fix scheduling back-logs by fiddling with the scheduling algorithm, no matter how much data you have.

Say the calendar is initially empty and 1000 people want to see the doc, right now. You can fill them all into the calendar, or you can play games that solve nothing, like only filling tomorrow's schedule with 10 people, asking 990 of them to call back. That doesn't change the fact that it takes 100 days to see 1000 patients. All it does is cause unfair delays; the original 1000 can be pre-empted by newcomers who get earlier appointments since their place in line is not being maintained.
Do 'maximisers' or 'satisficers' make better decisions?
If your home television supports Miracast, you can do it today: https://flathub.org/apps/details/org.gnome.NetworkDisplays
Bootstrapping is about the using income the business makes to run itself from the get go, and at most starting with a very small fixed amount of money. Self funding is taking money from your own bank account to fund the business. Very different things that are often conflated and confused for one another.

If you decide to bootstrap a business and set a budget, that's it. You don't get to add more to it, there are going to be very small essentials, but you don't spend any more money. Perhaps you spend a little money to buy domain name, but then you run on a dev server till it brings in income. You absolutely don't spend on marketing or paying anyone, until it brings in income to cover that cost.
> A third option would be to take a break from work and try to learn to write good code

I would say that learing to write good code takes practice and feedback, so if you want to stay in software engineering stay in your job.

Maybe switching to a field where basic coding skills come in handy, e.g. data science, would be an option.
If it had been written in rust or go, we already would have hundreds of MB worth of systemd binaries on our disks, like some other popular packages.

People all the time complain about systemd bloat, but it's very likely that in those languages it would be far worse.
I had many issues with the Python ecosystem. It's fairly fundamental to multi-project workflows to be able to use virtualenvs. Most of the community and tooling has centralised on them at this point. With VSCode you can launch the editor from a Terminal session with your virtualenv activated and it "Just Works". This will for the most part pick up your auto-formatter if you have one installed, that formatter will use the config in your project directory, etc etc.

With ST3 and the available plugins I was at the stage of editing my config every time I switched project to configure the paths, and it still didn't work as expected. Getting plugins to use config from a project directory rather than their own config was often impossible (e.g. black formatting plugin using pyproject.toml instead of the sublime black formatter configuration).

If I was working on projects with no other developers this might not be much of a problem, but working on a team where all canonical config is committed into the repo was essentially impossible.
Both approaches can work, but lead to different outcomes. The market for "todo list" apps is absolutely big enough there's room for more than one company.
The beauty of the bootstrapped model is you don't need to "win the market" or "beat the competition". Is it making a profit? Congratulations! You're now the owner successful company. Want to grow the company? Re-invest the profits, not your personal life savings.

If the goal is to "win"... ya, you're probably going to need to spend money like it's someone else's, and should take that VC money.
I'm not sure even "Senior" software developers will be able to understand badly written code at first glance. However what experienced developers will most likely do is make a copy of the code, open it up in a good IDE add a breakpoint and run it. Add your own comments to the code as you go along and figure things out. And don't forget to take some notes separately too.

As others have mentioned in the comments, you might be suffering from "imposter syndrome" but don't let it get you down. Some of the best out there have been through what you're experiencing [0].

[0] https://www.hanselman.com/blog/how-do-you-even-know-this-cra...
The Developers Who Are About to Lose Their PS Vita Games Forever
Having done that a couple of times during the last year, I don't really like it. The fact that it is recored makes obvious any flaw in delivery or hesitation. This leads to a long cycle of re-recording and re-editing that is very time consuming. Particularly grating is the occasional helicopter or lorry that goes by, resulting in yet another pass of recording and editing.

I also have to control everything about the environment (lightning, background, microphone and camera quality, etc), which is a pain compared to a conference organiser providing technical support.

So it is much more time-consuming to record the presentation compared to preparing it for live delivery.

I agree that pre-recording is better than live over video, for the reasons you mention (otherwise, there is nothing you can do regarding any stray helicopter or your router having a bad day).

I hate interacting in chat. Everything feels fake and wrong. People always need to pay attention to everything, lest they interrupt someone starting a sentence or trying to intervene (any latency is really bad in a vocal discussion). This is a bad imitation of chatting with other people over a beer.

The ability to re-record is a mixed blessing: it is a time sink and it is very difficult to be satisfied with the result if you are even mildly perfectionist. It would be better if we had access to professionals to record and edit talks, but we haven't.
I don't think you are a bad software engineer, most probably you are just not used to work in a big team. You are new in this middle size company and you are given the very badly written code which you are not familiar with at all. Most probably this code is big and exists for the long time and was modified chaotically to satisfy the urgent needs of customers. It is almost impossible to become efficient with this code immediately. May be I am wrong, but it seems you tried to work on your task without getting enough help from another people how know that code much better. The fact that your role is senior doesn't mean that you need to know everything and need to solve your problems alone. I work in a big company as a software developer and the interaction with people is the most important thing here.
As long as you change your UI.com password (and enable 2fa there) and disable the remote administration option, you should be all good.
>I'm afraid it'll look weird for the company interviewing me to hire a semi senior with +10 years of experience.

Weird? Not really. They may ask you about your career aspirations (they may think you will leave a month into a new role) and you should have some sort of solid answer ready. If they straight up ask "Why aren't you going for a senior role" you can say that you're not comfortable with the coaching element that most senior roles will involve. Or anything really - the specifics of the answer doesn't usually matter.

>I'm not sure if I can be a PM if I'm not able to code things the right way myself.

A Project Manager (I assume that's what you mean) does not need to know how to code things the right way. It's a very different set of skills and even if you're a terrible programmer than you will likely be in the top 1% of PM's in terms of programming ability.
Brief History of Semiconductors: How the US Cut Costs and Lost the Leading Edge
Your real problem is that you've had no mentors and that's not your fault. Software people need good mentors. Always being at a place with few or none programmers never gave you the opportunity to learn by example and that 10 years wasn't very valuable. You have probably grown some bad habits and lack the understanding to recognize them.

If the people you are working with now are nice then you should take this as an opportunity to become the senior engineer you thought you were. Hiring people is annoying and if you are personable, humble, and eager to learn more often than not they would rather train you up than get rid of you. You did the fake it part, now do the make it part.
Plausible is great, and I see the need for it, but I've always enjoyed using AWStats instead, as there is no need to add third party code to my site. It all happens in the background and it paints a much better picture of your stats since users can't block the gathering of stats with an AD-Blocker.
That's a cool idea, though why limit it to US cities? Wouldn't cost much to just allow creating/searching in the whole world.
Could also be nice to have "language" selection, so that I can know if it's fine for other players to include a non native speaker.
Every merge is a risk of merge conflicts, of bad auto-resolutions (don't get me started on the circle of pain where you need to understand git rerere and its consequences). Just because there are auto-resolutions and they mostly work (most of the time) automatically doesn't mean that all merges are safe. (Fast-forward only merges being an exception, of course.) Rebasing hides the history of those merges, their conflicts, their resolutions. Merge commits do provide all sorts of useful information in the cases where merges go wrong. That information is entirely lost in rebases, depending on the user that did the rebase and how they do the rebase.

I understand many people consider merge commits noise. I think rebases are destructive and dangerous. I'd rather have an extremely "noisy" git graph that I can manage with UI tools and filters like --first-parent than a "clean" git graph with no way to research and/or fix a bad merge after the fact.

I realize those are often very opposed viewpoints, I'm just offering mine in a thread full of people who don't shudder every time they hear a junior developer attempted a rebase or amended a commit in a branch they shouldn't have.
Exactly this. My current project is on full .NET Framework 4.8. It is on the latest possible version of ASP MVC, Entity Framework and all typical 3rd party libraries(of which 90% is supported on .NET 5). In the last two years we created several POCs for migration to .NET 5. Our current best estimate is 7 years for 80% of our development team. No sane manager will ever approve that crazy effort with almost no benefits for end users. Additionally we are talking here about most typical CRUD application without almost any advanced engineering. Our onboarding is taking at most 2 days and people can start be very productive even in first couple days. I can only imagine nightmares with more complex systems.
Now that I understand this functionality better, you may be right. I'm on the fence about whether it really should be built-in, but I can appreciate why you'd want it to be.

In effect, you're asking for the ability to extend the list of supported languages by specifying them on an ad hoc basis, and I can definitely see why that's an absolute must-have if you're working in a language that isn't built into the editor. (I really hope I'm capturing the functionality correctly.)

That being said, I suspect most developers rarely work in languages that aren't supported, so even IF this should be built-in, it seems like something that most users would never use. While I think that's perfectly reasonable in an IDE, I think a text editor should be limited to features that are used by a majority of its users for the majority of the time.

It's not that I'm saying this isn't crucial functionality. It's that if we start requiring text editors to have every bit of crucial functionality that anyone might have, you end up with an IDE.

I still think the problem is the plugin ecosystem. What would stop the Sublime team from saying, in effect: "This is functionality that should always and reliably be available for those who need it, so we're going to take responsibility for maintaining this as a plugin"?
There's this myth that the PM must have knowledge in the field. The best PM I've ever worked with never touched code.
Songs wouldn't get played on the radio without sponsors placing adverts on the station. Maybe we should cut the sponsors in as well?
systemd unit files are a massive step up from the old way - they properly handle dependant services, running as a user, can handle restarts for you etc. And as you say, no more annoying boilerplate!

Actually, unit files are possibly the only part of SystemD that I've knowingly interacted with - I know it does about a thousand things, but whatever those other things are, they are transparent to me as a user.
I bought the product in 2015. I don't remember the cost but let's assume it was $80. (EDIT, I just looked and it was $70 at the time) That's $16 a year. If you use even 5% of the functionality, isn't it worth that? I don't know what country you are from and there my be economic differences but sublime text has been one of the best software purchases I've made. It's worth every cent.

If you don't feel it's worth $80, you can use Visual Studio Code for free.
We got to start manufacturing everything locally.
But does the Bond villain ever know they are the Bond villain? Or are they the protagonist of their own self directed story.
Poland and Hungary are into this trend, so is Russia. These are the countries that host the majority of the people in the eastern part of Europe.
Thank you for this read. Very observant and insightful in only a few words. Communism is the outcome if this mindset continues. Like you said, we must teach others not to believe the lies of victimhood. Thank you so much for sharing. Teach it to all you encounter.
The BSL license makes choosing it "a discussion" versus using OSI licensed software: https://github.com/vectorizedio/redpanda/tree/v21.3.7/licens...

I don't have enough experience with these new vanity licenses to know what the contribution story looks like, either
I think this is something to be solved with pkg-config(1). Autotools already uses pkg-config to find dependencies and query for any extra flags needed, and with PKG_CONFIG_PATH you can have the program prioritize your own installation.
This Question Will Change Your (Reading) Life