I took a functional programming in Haskell course first year in Uni without having much previous programming experience at all. Quite early in the course we were tasked with implementing a huge bidirectional graph and an efficient shortest path algorithm for finding the fastest way between any two nodes.
I hadn’t taken any DSA course and was totally unaware of graphs and shortest path algorithms and the course material was pure Haskell syntax.
I failed miserably and so did most of the others.
Capital M is for Mega.
I would use duration_s and duration_ms.
const duration_ms = 1000 * duration_s
And _us for microsec.
const duration_us = 1000 * duration_ms
But then the tool would probably reject my code for not following the naming conventions which ”disallows using underscores in variable names”.
Guess what I wanted to say is that there are always exceptions to the rule and there should always be some way to turn off the automatic checker for certain sections of the code.
I second this. My impressions so far are pretty much the same.
Have been trying to get ChatGPT to generate code for some algorithms that are pretty close to well known implementations but with some twists and it absolutely fails no matter how much I tried to provide hints to change the suggestions it gave me. In the end I just went back to hand coding them since it actually saves me the frustration of trying to get ChatGPT to bend in the direction I need.
Agreed. A comment can also explain things that a function name cannot.
I’m all for splitting code into paragraphs with a well written comment above each.
Of course I also extract functions, but only when there are obvious benefit, like removing repetition.
I'm having a hard time believing that world's top talent in software development are fighting to get into Swiss banking. What makes you think that the brightest people are striving to get employment at your bank?
If it costs $200 or whatever and would clearly save you more than that in time ($200 is a few hours of developer time) then surely it's worth it. I guess the problem is that the process isn't in place to make buying CLion easy, so there'd be a lot of administrative overhead. Or no-one cares about maximising productivity. Or it's not clear to them that CLion actually is better than alternatives. Or maybe they want all developers using the same tools so any process improvements are shared.
None of those seem like great reasons tbh, but I did just make them up as part of a strawman to lambast your employer.
My experience is that the expectations on what your average engineer should be able to handle has grown enormously during the last 10 years or so.
Working both with large distributed systems and medium size monolithic systems I have seen the expectations become a lot higher in both.
When I started my career the engineers at our company were assigned a very specific part of the product that they were experts on. Usually there were 1 or 2 engineers assigned to a specific area and they knew it really well.
Then we went Agile(tm) and the engineers were grouped into 6 to 9 person teams that were assigned features that spanned several areas of the product. The teams also got involved in customer interaction, planning, testing and documentation. The days when you could focus on a single part of the system and become really good at it were gone.
Next big change came when the teams moved from being feature teams to devops teams. None of the previous responsibilities were removed but we now became responsible also for setting up and running the (cloud) infrastructure and deploying our own software.
In some ways I agree that these changes have empowered us. But it is also, as you say, exhausting. Once I was simply a programmer; now I'm a domain expert, project manager, programmer, tester, technical writer, database admin, operations engineer, and so on.
It sounds like whomever shaped your teams & responsibilities didn’t take into account the team’s cognitive load. I find it’s often overlooked, especially by those who think agile means “everyone does everything”. The trick is to become agile whilst maintaining a division of responsibilities between teams.
If you look up articles about Team Topologies by Matthew Skelton and Manuel Pais, they outline a team structure that works for large, distributed systems.
> None of the previous responsibilities were removed but we now became responsible also for setting up and running the (cloud) infrastructure and deploying our own software
On the flipside, in the olden days when one set of people were churning features and another set of people were given a black box to run and be responsible for keep it running, it was very hard to get the damn thing to work reliably and the only recourse you often had was to "just be more careful", which often meant release aversion and multi-year release cycles.
Hence, some companies explored alternatives, found ways to make them work, wrote about their success but a lot of people copied only half of the picture and then complained that it didn't work.
Ah excellent. Yes. In my experience there's this idea of "scale at all costs"--a better way would probably be to limit scaling until the headcount is scaled. Although then you probably need more VC money.
Might I add that you are also now underpaid. I had a sweet gig at a very small company where I had to manage contractors in addition to FTE staff. The good contractors billed $300 an hour for BA and project management services alone. The story munchers billed $150 an hour.
I had to leave a contracting gig recently because we were tasked with everything...literally everything. Everyone got so burnt out--FTEs included. I also might add that the developers could have spoken up and gotten relief but their misguided work ethic prevented that.
It’s interesting to see these salary levels. A senior developer (10+ years of experience) here in Sweden is paid less than their entry level salary.
The difference in pay between Europe and the US seems huge. I wonder why.
I am disappointed this comment does not receive more comments! I feel the same. From far away, it seems like Berlin is bursting with great technical talent, as well as Copenhagen, Stockholm, and Helsinki, yet the salaries are terribly low. (I see you Oslo, but not the same reputation!) Oh hey, please include France. They have such great, underrated technical universities... do amazing comp-sci research... but their commercial software industry is so small!
Some theories:
* High taxes actually means lower gross pay? (I am someone who strongly supports the "social safety net" -- do not read that question as some kind of weirdo libertarian / low-tax promoter.) As a counterpoint, usually high taxes means higher quality of life.
* Or: Labour mobility is higher in US than many high-tax, strong-labour countries in Europe/Japan/Korea/Taiwan. In short: It's easier to hire and and fire in US. As a result, I see massive income inequality in US, but much less in wealthy European countries -- and Japan/Korean/Taiwan.
Another way to think about it: If software engineers are paid 50% of Silicon Valley in Helsinki, then Starbucks baristas are paid 100% higher in Helsinki. (I have no hard references to offer... but my point: Lower skill jobs pay living wages in Northern Europe/Japan/Korea/Taiwan, but less in US.)
Personal question: Would you prefer to live in Sweden with your current wages, or a place with "up 100% wages for you", but much higher income inequality? When you answer, please assume much higher personal crime rates and visible poverty (or working poor).
I live in a place with simply appalling incoming inequality. The visible poverty and working poor are so depressing. I would easily take a 25% pay cut to build more social housing and help the elderly who collect cardboard to retire immediately and play with their grandchildren all day long!
The income inequality in the US is not that visible in day-to-day life. A large fraction of the income inequality is a side effect of the scale of US geography. The States with the highest and lowest median incomes are separated by 2x income and 1500 kilometers. It is also worth pointing out that even the poorest US State (Mississippi) still has a median income that is the same as Germany, so "poor" is relative.
Different States have different economies due to geographic locale, history, and specialization. Consequently, the US has States that specialize in agriculture, manufacturing, services, technology, natural resources, etc which have very different economics and compensation structures which is reflected in local incomes.
The median income is much higher in Washington than Mississippi, for example, but that doesn't imply anything about the distribution of income within those States. It would be like comparing incomes between the Netherlands and Romania.
Closer: San Francisco: Montgomery Street business district vs Tenderloin district
Even closer: Mission District -- Mission and 16th Street. Walk east one block and you reliable find used needles on the street. Walk west two blocks is quickly wealthy.
New York City: Manhattan vs Bronx
Closer: Upper East Side vs East Harlem (125th Street and above)
All of these pair are close and would surprise many by the huge gap in quality of life between both of them.
This one should be like catnip for HN: Palo Alto vs East Palo Alto
It's hard to answer your question without actually experiencing the differences first hand. It's not like we don't have visible poverty in Sweden. Almost every day I see people digging through the public trash bins for bottles and cans that pays a little for recycling and there are beggars in front of the stores and approaching you on the street asking for a money.
There is however a base pension that each senior citizen is entitled to. About 15% of the elderly only gets the minimal amount which in many cases doesn't cover basic expenses, like rent and food, so they need to be on social welfare as well.
But would I accept a 100% salary increase if it meant that social welfare had to be removed and people couldn't afford a place to live and to put food on the table? Of course not.
Would I like if people that study hard and get well educated also get well paid jobs? Yes!
Different idea: If you get the chance, take a very high paying job in the United States for a few years. You don't need to stay forever, but you will see with your own eyes... and make a bunch of money. You'll be "richer" in more than one way -- savings account and experience.
I pay some of the highest taxes in the country in exchange for some of the worst highly-visible poverty and most dysfunctional public services. Either would be a huge improvement.
Yes that is something that comes up on hackernews a lot, and I personally still struggle to accept it.
According to the Daily level system I should be in their band 5, so $210K, but in England I am paid less than half their entry level salary (at current exchange rates).
Americans don't have IQ scores, or any other metric to suggest being approximately 4-8 times the quality of other developed countries workers, so it's hard to just take it and accept that their compensation isn't due to their ability (on average), and that life isn't fair.
I am an American who has worked in Europe for many years at multiple companies, so I feel at least somewhat qualified to give some insight.
Europeans are just as talented technically as Americans, that has never been the issue. As a broad generalization, European business culture is consistently poor at leveraging that talent to generate value, often treating it like factory work. Because American business culture is so efficient and effective at converting engineering talent into revenue, often on the scale of $1M revenue per engineer, they can easily afford to pay the higher wages while still making a fine profit. This has the side effect of making the market for engineering talent extremely competitive.
In short, European technical talent as a resource is often being wasted by poor business practices, which means there is much less money to go around. There is no reason in principle that European engineers could not earn much more in Europe but changing business culture is slow, though some companies are trying.
Yes, I am aware that the salary for an entry level employee on the Daily system is more than the total value I bring to my employer per year. I am paid less than half because I already eat up about 60-70%* of the total income I bring to the company.
The ability to earn American style wages, without trying to emigrate, is entirely out of my hands. There isn't anything I can do short of risk homelessness for myself and my family in the attempt to create a better business (which I am incredibly unlikely to be able to do).
* depending on quarter, project, year by year, etc.
Thanks for this comment. A very interesting observation.
Do you have any thoughts regarding American companies that are established in Europe, shouldn't they be able to introduce that American culture in their European offices?
A very interesting follow-up to an insightful post. I think the answer might lie in why the american business culture is more efficient in the first place.
I believe american business is more fluid, allowing for better arbitrage opportunities that ultimately leads to better arbitrage abilities for its actors.
More law and protection has the same effect as more code: it slows things down because it increases dramatically the amount of requirements you have to contend with. A double edged sword indeed!
Premature optimization is a common disease amongst C and C++ devs. I often come across code that is written in an obscure/complex way just because someone thought execution speed triumphs code readability.
In most cases (around 9 times out of 10) it is on a non-time-critical path of the code and the developer who wrote it didn't even bother to run a profiler on it.
My work would be significantly easier if we could learn to prioritize code readability.
The point of those languages is to make it explicit when you're doing ridiculously costly things so that you're forced to do a reasonable implementation instead.
No, any language that allows operator overloading can hide ridiculously costly operations behind mundane-looking code. C is pretty good about that, but C++ is not: you can even overload the comma operator!
When you read the code, you know what the types of a, b and c are. You know whether they're built-in types, and therefore whether those operator expressions are actually function calls.
Nothing is hidden, so long as the programmer doesn't make invalid assumptions based on his experience with other, different languages.
Your point appears to be "if you know the entire codebase, nothing is hidden." This is tautologically true of all languages. If you're accustomed to working on small projects, then that attitude will work out for you. If you work on large codebases, it isn't always so easy, especially if folks use a lot of template magic.
In your case, if a, b, and c are all the same type, then b+c can return a completely different type, and you'll need to track that down before you know what type a+(b+c) will have. And in that case, (a+b)+c can have a different type from a+(b+c). If you've memorized the associativity rules for the language, you'll know what to expect -- but it's not at all obvious from the notation.
And, sure. If you know absolutely everything about the language and everything about the codebase, you can make accurate predictions about the behavior of any given line. But if you're coming into a new codebase, there's no way to know at a glance what a given line of code is going to cost. That's what folks are calling hidden complexity.
Oh -- and thanks to the auto keyword, you don't always know the types of a, b, and c without hunting things down.
You don't need to know the whole codebase to understand a piece of code, just what the declarations of the names being referenced in that piece of code are (in C++, a name may be a macro, a type, a template, a variable or a function, and depending on which kind, may have all kinds of other properties attached).
Yes, you need to look at the declarations of names to know what the resulting type of expressions involving those names is. I don't see that as being surprising or unusual. The same is also true in C.
It's impossible to tell whether a specific line of code makes a copy without knowing the types of all values. i.e.
std::vector<int> numbers = Func();
may or may not make a copy depending on the signature of Func. So it's not clear at the callsite how expensive that line of code is. This is unlike Go (which has this explicitly as philosophy) where you need to call a copy function/use append to make a copy of a slice.
