We do work at those, but fundamentally, skills at (1) working well with a variety of people and (2) understanding systems and their interactions well enough to hypothesize and test for causes of faults are both things you can have more or less talent in, but they're fundamentally skills that come as the result of substantial experience working with different people and working with complicated systems.
You probably can't properly learn these without spending the ten years, but you can choose jobs and colleagues and experiences that will help you learn them better. Better to focus on emulating how people learned these skills than trying to skip the hard part.
I currently work on a team of 10 engineers and 2 of them over 50, asked me what was GraphQL, when I did a public demo on GraphQL APIs around it. We are in a department that runs an e-commerce product with 30mil+ monthly visitors.
How does a 25, 26, 27, year old automatically mean bad at public speaking...? Personally, my best manager has be 28 years old.
It may take 10 years to blindly learn these skills but with a single, good mentor you can learn it quickly. I think most senior developers dont have the patience nor the transparency to lay this out though. Its a very honest conversation to have with someone - "Hey that idea you had is a good one but your presentation of it is problematic. Here is how you can make people more likely to see your point of view" is not as sexy as debating microservice vs monolith.
The best thing universities can do is to instill an understanding of soft skills in people. They should come out of university knowing:
* How important soft skills are
* That they are the differentiator between senior and junior
* How to best learn them (don't hunt highest pay, hunt highest experience gain)
In that respect I've learned a lot more from projects that have gone off the rails to some degree than projects where everything went according to plan.
In an ideal world you have the opportunity to give each person on the team the right amount of risk with enough of a safety net so that if things really go sideways the team has their back. Finding the balance with the rest of the project requirements, business inputs and other pieces is where it gets interesting.
I had a manager like that, and I made the mistake of confronting him for ,,safe'' and bad technical decisions (in which case the higher level person always wins), instead of just nicely switch teams without confrontation.
Then it hit me, the images with words on it every few paragraphs were the pieces of advice! They were not ads or merely unimportant illustrations, they were the titles! I unconsciously ignored them all on first read, banner-blindness or something like that.
I actually scanned the post for bullet points the moment I opened the page and couldn’t find them. Because the bullet points were designed as images.
Important to notice that now, looking at them as bullet points, I like the design. They useful mini-posters. But they had this side-effect on me of magically becoming invisible.
If it allows you to provide more ('stuff', or security, or stability) for a family, then yes, it might make you happier.
I read articles like this and they mostly tend to be from the perspective of younger people and/or folks without families to support.
An extra 10% pay increase, over just a few years, provides more general savings, perhaps buys solid life insurance, helps pad savings for future education, or moving expenses to fund a job/life change, etc.
Another nugget - "Know your worth". It's not bad advice, but something the author didn't mention was understanding how your worth is determined. You can do the exact same work for company A and company B. Company A may be able to extract huge value from your work, and company B may struggle to keep the lights on. When working for someone else, "your worth" is directly related to how capable they are at operating their business profitably.
I've no doubt the author's views work for him, and probably many people like him, but as with most posts like this, they're not universal.
The older I get, the more I see less the great outcomes when adversity hit people I know (whether death or illness or some other big hit). Money isn't everything, but in many of those cases, having an extra $k saved up would indeed help smooth people through those rough patches. I'm actually amazed at how many folks work for decades, then something happens, and there's a gofundme set up for the family to help with day to day bills.
If you have all your financial ducks in a row, everyone is comfortable, and you have the life you want, that's great. To each their own, indeed! :)
Not to go all Bernie Sanders on you, but... welcome to America?
Maybe you don't live in the US. But here in the US, a single medical bill can wipe you out. And because we value free market healthcare, that means you don't know what the price will be until after you receive treatment. You won't know if you're covered or denied coverage until after the incident. Because that's how the Free Market(tm) works.
Be thankful if you've never had the luxury of spending months battling a massive bill you received because one of the ten random people you saw one night in a hospital was out-of-network despite being at an in-network hospital.
You don't have to be a full blown socialist to see how fucked America is.
I've not quite had the situation you've mentioned with medical stuff, but have had some ER visits which end up costing thousands out of pocket on top of the ~$10k/year we spend on insurance.
For people I've known who were in software, or engineering, or law, and had high-paying careers over decades, to know they were still living that close to the edge financially, that's what amazes me. And sometimes it's bad spending habits (or drugs, or whatever), sometimes it's just poor financial education.
But to the original point - an extra ~10% year in income to many folks - even if it means a slightly reduced 'quality of life' by some measure - can have an impact on their lives down the road, but they also need to manage that extra income properly.
Not sure what the takeaway is here, just wanted to express my thoughts on it. Soft behaviors seem both like some enormous formless cloud that you can't really define and a rock-solid mountain you have little hope of moving.
Also, reading this on his own website instead of on medium is a much better experience, definitely recommend.
Every time you have the “wrong” action think about the “right” reaction. Over years your “natural” reaction will change.
This is psycho advice. It ranks up there with the crazy myths about just being able to instantly get new software jobs (when the actual time of job searches is usually longer than 6 months, despite the tone deaf wave of gainsaying comments this is sure to incite).
Voting with your feet rarely leads to organizational changes, especially if you don’t give clear feedback or spend sincere effort trying to fix the issues you’re having prior to quitting. More likely, you quitting is just tacitly reinforcing power and control by the shitty people who made your experience shitty.
When you need to quit, by all means, absolutely do it. But don’t kid yourself that there’s any “voting” going on. Do yourself and others a favor: give feedback and take responsibility for your own job satisfaction. Nobody can help you if you won’t try to get help.
And don’t count on a fast job search. This topic is so tone dead on HN. Some cacophony of commenters will swear you can get a million jobs from all your spam LinkedIn headhunters and be re-employed in weeks, but it is emphatically not true and the selection bias of those examples has to imply just ignoring them as inapplicable to the vast majority of software engineers. Interview prep, finding a good fit and getting what you want in a position and in compensation is really hard and takes a long time in software.
Well, everyone I know who's any good as a developer can just waltz into a new job on Thursday after being fired on Tuesday.
/s, if it weren't obvious, but I've read enough straight-faced comments of this type on Hackernews.
And I do agree that it's rarely going to lead to any sort of corporate change. I worked at a place with around ... ~20 IT folks. New CEO came in, and within 9 months, 8 of the 20 had left or were leaving (I was one of them). I'd reached out to the previous CEO (who still owned the company, had interviewed me, and was one of the reasons I'd taken the job) and said "something's wrong here". "I don't want to hear it - talk to New CEO". "New CEO is the problem..." "Don't want to hear it...". So... loads of people left. It wasn't until New CEO tried to get rid of one person in particular did alarm bells finally go off, and owner/CEO came back and booted New CEO. So... change happened eventually, but not in reaction to 40% of the IT staff leaving in less than a year.
my linkedin profile: literally just desktop c++ work in a completely different domain.
yeah, something tells me these messages are not likely to lead to a real job.
in any case, I really like my current team and manager. it would take a lot more than a €6000 (~$7000) salary bump to make me consider a different job.
Not all advice is literal.
Also, not everyone’s goal is to foster organizational change some are trying to help themselves first.
The author mentions COBOL as being antiquated and irrelevant but in all honesty, modern languages don’t improve upon much. Underneath all the layers people add to modern languages (so the rest of the developer community can push buttons without even the faintest idea) lies assembly language and the machine.
Knowledge of the systems is abstracted away so much that people are focusing on mastering the wrong thing. One should be able to implement algorithms in C or COBOL or even assembly. Otherwise, it’s like learning to google the notes of a concerto without understanding the chords, scales, harmony, melody, etc.
> When Jon Bentley assigned binary search as a problem in a course for professional programmers, he found that ninety percent failed to provide a correct solution after several hours of working on it, mainly because the incorrect implementations failed to run or returned a wrong answer in rare edge cases. A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks. Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years. The Java programming language library implementation of binary search had the same overflow bug for more than nine years.
Knuth had this to say:
> Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky
If the experts can't get it right, no developer in an interview setting has a chance. It's a game of "gotcha." The interviewer has some trick that they are privy to and are waiting for the interviewee to mess up and... GOTCHA! You got it wrong, it's this clever trick that you would have to know ahead of time! Silly person thinking they can get a job here without knowing the secret handshake.
They suggested one should have to know how to implement algorithms in Assembly to be useful.
Also the article author mentioned bubble sort as an example. Do you really need to know bubble sort by heart?
Sure, you could get through the situations I'm thinking of without knowing anything about this, but if you don't think about it, you risk filling the code with lots of O(n^2) loops that could be O(n) if you added an extra map. This is how you end up with applications that are slow due to a thousand small cuts.
If you don't think about these things, then I can only assume that it's because you don't notice them when they come up.
To be clear, there's nothing wrong with choosing the slower implementation because its simpler. What's important is that you thought about the trade-off, and often the O(n) loop is not more complicated than the O(n^2) one.
There is no obligation for you to stay in a job you don't like, or to pursue a different opportunity. You don't have to explain your reasons for leaving. Your employer and your team will probably be fine without you, and if they are not it is not your problem. To often I've stayed in a job I didn't like because "I'd be letting my team down" or "we're too busy, now is not a good time." Screw that. If you are not liking it, find something else and leave.
I'd also add one more: "Take your vacation". You are no good to anybody (you, your friends, your family, or your employer) if you work self to burn out. It's not worth it, and the world won't end while you are away.
I've always been a fan of 'pi' shaped skillset where you're deep in 2-ish+ areas rather than one core skill. It also means that you don't become known for just one singular thing. This becomes even better when the your deep areas complement each other and you'll find the sum greater than the parts.
Too often, the answer I give when asked "Could the software be made to do X?" is "Yes, it could, but no, it should not."
The exported data is in CSV. Excel can import it. Yes, I could import an Office library and write XLSX files natively, but while the person making the request screwed up by making the wrong selection after marking up the data with colors and saving it as a CSV, dropping those features, the right thing to do is not screw that up, not to add complexity to the software.
Like, ask for help? You need to learn to solve stuff without disturbing the team.
Vote with your feet? Juniors are not in the position to do that.
People can't read your mind? Actually people are quite good at reading your mind and alot of things are supposed to be said by indirect hints to save face.
Soft skills? Way overrated - just don't be toxic and avoid obvoius trouble.
Know your worth? Build a brand? Say no?
This guy is just listing stuff he gets away with by not being new to the field. The advice would be worthless to himself when he bagan ...
The one advice I would like to have had is "no-one will notice if you give 110% or keep a 60% substainable pace. Relax and keep grinding".
I really hope this is hyperbole, but you should never use bubble sort. I can't think of a single legitimate reason you'd want to use it. Insertion sort, is a good O(n^2) sort to know.
When would bubble sort be ideal? When it's relatively cheap to read data sequentially compared to backwards or randomly, and resetting to the initial read position isn't too costly.
Now I've nerd sniped myself, and am brainstorming how that situation might arise with modern systems...
If there are instead two people to sort the deck of cards, they'll probably invent some variant on a merge sort!
Learning how to properly estimate a given task and delivering it on or before your proposed time-frame will make your life as a developer much better.
Questions need to be in pursuit of some goal, with different options for implementation. Usually you'll get a question with a fairly simple naive implementation with terrible performance, then other options which have more favorable worst case running time.
I've never needed to use one, I can just do .OrderBy() or similar in the language I use.
Does that make me a bad developer?
I do remember Barack Obama advising against bubble sort though.