Learning how to pair program effectively, and pass along skills to others. Performing great presentations and demos, and writing about your work. Being able to avoid complexity by finding simpler solutions. Separating yourself from your code and being open to criticism. Studying how goals, objectives and tactics relate to actionable tasks a software team needs to execute on. Becoming better a time management and prioritization, and delivering value faster.
None of these are very technical skills, but they require a lot of practice and a ton of patience.
How do you increase the quality & output of your entire team/org/company? Better features, fewer bugs, faster releases, etc. Learn what it takes to effect that change, and then learn how to make that impact wherever you are.
If you don't invest a piece of your work week mentoring juniors, you're a lot less productive than you could be.
At least where I work, the "workhorses" are the ones training the new guys.
That doesn't mean you have to eliminate the workhorses, but you need to convert them from being 10x engineers to being 10x multipliers.
This is the valuable and essential element of personal growth that I'm espousing - teach yourself how to multiply the team's output.
While my outsized code productivity was decreased to near zero, my team is moving faster, which benefits the company over the long term, as well as me being able to gain the skill s needed to help mentor people in concrete fashion to become better engineers.
By stopping them from producing things of value? How does this make any sense. It's the peter principle all over again.
10x + 1x + 1x = 12x
Now you convert that 10x engineer into a 10x multiplier, and let's assume he doesn't actually do real work anymore because he's helping everyone else be more productive:
0x + 10x + 10x = 20x
He may no longer be doing any work, but the rest of his team is more productive and significantly outstrips his own individual output.
That's some very impressive made-up math!
Obviously the real world is not so simple, but the effect is the same. There's the engineer that cranks out a crazy amount of code and nobody can keep up, and then there's the engineer that helps everyone else crank out more code - now everyone is learning and increasing their output. Which would you rather have on your team?
6x + 3x + 3x
Where your 10x reduces their own output to help the others triple theirs. This:
- doesn't decrease overall productivity (still 12)
- probably increases consistency across your product (with workloads being spread more evenly)
- increases bus factor
- will lead to productivity gains as the team grows
Some people that you may be working with are simply resistant to actually expending a portion of their own day to learn/grow. Even if directed by others, or when you try to help. I do find that the best use of that bending of wills is participating in regular code reviews. Offer suggestions of things that should be changed before accepting, and other things that should be done differently in the future.
When you do that, you'll see your peers taking on more and growing over time. But it isn't easy, and will never be thatn 0x + 10x + 10x that was suggested upthread.
"On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer"
In the meantime, many of us are happy enabling other people to be more productive and making an amount of money that can certainly be described as satisfactory.
But even if you want to maximize salary, being a 10x multiplier on a team in a large company is a very different thing from running a company. (And running a company is a very different thing from necessarily making insane amounts of money)
As far as specific tech, my crystal ball is a bit fuzzy right now but AI seems a decent bet.
>Being able to avoid complexity by finding simpler solutions.
This is one of the most important ones, IMO. Sometimes it may also mean reducing the size or scope of the problem itself - because YAGNI (where Y is the customer), or AYRSYNI (Are You Really Sure You Need It - TM me :). Seen it done by my managers a few times, and done it myself a few times (sometimes successfully, sometimes not), as a consultant.
Also, googling for links for YAGNI, TIL about:
I had read about in a book by Steve McConnell, IIRC (maybe his book Rapid Development), but did not get a chance to try it in a real life project - yet.
Perfect example, starting on a new SPA, wanting to use latest/greates React/Redux/Webpack/Babel tightly coupled to a Node API latest Koa and it's ilk. For the life of me, could not get the Webpack dev server bits to work with Koa. Spent about a day and a few hours on it... finally decided to run the node server on a separate port, and have the webpack dev server set to reverse-proxy to it. I have no current plans to run websockets on my backing service, so it works for now, but not the integration I wanted, the way I wanted it.
To me, it's just being pragmatic with my time... I was explaining to a friend who asked, "were you pressured into these time constraints...?" and my response was no, it's just I wasn't going to delve into a week+ of work to get things the way I want only to provide minimal value, while the larger OSS dev community will likely provide a better solution before I can circle around to it.
I love OSS, I participate when/where I can, and appreciate all that everyone does. If you're working on something that can be separated out, that isn't a core to your business, why not put it out into the world and save someone else some time down the road. I mean a lot of things are of varying quality, but if they provide value and save myself or someone else time, I'm all for it.
Where I feel bad are the projects that start off small and hit a critical mass where the support exceeds the time/expense to support something. It's always a matter of reaching a pragmatic balance to one's efforts.
Any thoughts on the best opportunities for tech-oriented people who don't want to fit themselves into teamwork-focussed environments?
I'd argue our field is past the point where writing any unqualifiedly impressive project is within reach of a single person, no matter how talented.
Bitcoin, Minecraft, Bittorrent, Spark, american fuzzy lop, Tarsnap, PGP, and many more.
You do have a point that solo brilliant engineers can start projects that go on to have massive impact (cough Linus Torvalds), but once those projects have reach, they tend to have teams.
The most recent one that comes to mind are redux + redux dev tools. Though definitely have grown since initial implementation, it was one of the more impressive things I've seen recently. Second in my mind is git itself.
When working solo, there's nobody to insulate you when your soft skills are lacking.
There are aspects of all of the above I tend to appreciate greatly, it really just depends.
2. Work on resolving whatever issues led to the dislike of teamwork in the first place.
Also, "The Phoenix Project" which IMO is a groundbreaking work on how to make IT/business more effective (and the start of the DevOps movement).
Even if you're not a manager, both books are very approachable and packed with great lessons about how improve and better work with people, teams, and business.
I'd argue that you are better off doing anything but programming in your spare time. For example, learn some artistic skills, such as actually painting, or drawing, or playing a musical instrument. Or master a sport, or some other physical skill like woodworking.
Don't devote every hour of your life to just one thing. You already spend a third of it programming. That's enough. Step away from the computer and become a more rounded human being.
In this case, there could still be room in engaging one's creative side through a side project. The key is that a side project like this shouldn't feel like "work". There's no use cargo-culting the side project craze if it doesn't flow naturally.
For example, I have a friend who's currently working on a home automation project that involves significant programming. I can tell it brings joy to his life, the same way that painting would to an artist. Maybe this doesn't make him more "rounded", but what's the difference? When I see him talk about it, his eyes light up with the same passion I see from those in the traditionally "creative" fields.
In the same way, I love spending time using Jupyter Notebooks/Pandas to do rudimentary data analysis. It's fun, and I've learned a ton, some of which has come back to help in my day job.
The expected value of generating evidence of your "passion" is actually pretty high, given how strongly people who hand out high salaries (and interesting work) prefer to hire those with a propensity not only to spend every waking hour working, but to be happy about it.
Conversely, the job prospects of an unabashed "9-5 programmer" aren't great. It isn't in your interests to give the appearance that 8 (or 10) hours of programming every day is enough.
I'd guess that most hours sunk into side projects are seen by their creators as the hard work necessary to enter or advance in the field, more than as leisure time.
Both times consisted of intentionally breaking things and fixing everything that was broken in the new way. Both times I was jokingly referred to as the "king of refactoring." After some relatively bad experiences late last year, I was offered the job I have now working with a few of the people I worked with then, based on that experience.
You don't always have to be afraid to make a sweeping change, but you should have a plan, and should try to execute with minimal impact on others. The date-time one was triggered by having to drive an hour into the office, at 1am because of a bug in a deployment update... in the end, it was easier to rip out and replace with something more consistent.
Also, there are times where you can break something off into something that can use newer tech... such as a minimal node api connecting to a search database that's feed updates by another mini service that replicates data from an sql db...
Try to dedicate a portion of your day/week to exploring how new things can provide value... get it done. As Admiral Hopper said, "it's easier to ask for forgiveness than permission." Sometimes in the face of contrarianism, it's easier to "just do it."
Does doctor, GP, engineers, scientist, ... expected to do the same ?
Because when you jump one level up on the pay scale, there is no expectation of you learning anything whatsoever, at least not outside company time. Similarly, a developer setting a meeting to learn about a technical issue is frown upon, while manager setting up a meeting to learn about a business functionality is perfectly ok.
That's how you end up with manager only workshop, but developer should magically figure it out what to do and how, all from the workshop reports.
If you're working in an environment where this is frowned upon, you're in the wrong environment. Get out. Places that know what they're doing will actively encourage learning - particularly cross-team knowledge sharing. Whether it's lunch-and-learns, Friday afternoon sessions or random "jump into a meeting room so I can teach you all about this thing I just learned", it's always important to have learning within work hours - it's the only time you'll get everyone together at once.
If you can't get 20% or so of your work time for self/team improvement, then your job is going nowhere. As for doing things on your own time... software development can be an engineering discipline... however, in practice it's more of a craft. Most of the better craftsmen I know, and know of, spend a lot of their own time working on their craft.
I agree though that just writing more code is not the answer. Different people have different appetites for things, and I find a lot of my side projects involve no code (I sometimes do actually paint), but I don't value them any less for it.
On the flip side, I tend to not do activities like conferences that take me away from work for days at a time. There's nothing wrong with setting aside part of your work week for growth. As long as it's known and accounted for, it shouldn't be an issue. My time estimates for planning are 5hrs/day. I also over-estimate by about 30%, where most tasks are delivered in about half the time, and the rest even out.
It's not about spending every moment of your work day doing the core work... if you're a developer you aren't a cog, you're a craftsman. You need to spend time honing that craft and your skills or you won't get better at it.
I do agree on the learning other things, and doing other things... most craftsmen will grow significantly with more exposure to other skills/crafts and arts. But that doesn't mean that you can't spend most of it on your work focus.
By far the most under-rated and the most useful skill to have as a programmer.
When I seriously started programming, I spent one hour every day for 30 days on typing using one of those many typing softwares.
The first thing I noticed was how much less thinking I was doing with regard to my typing. I didn't have a part of my brain guiding my fingers any more - the fingers already knew. The other thing I noticed was that I wasn't typing by characters, I was typing by word.
With these two things I was already able to write programs faster.
But the other things I've noticed have happened so slowly that I almost didn't realize it. While typing, I can see a broader swathe of the program on the screen than I used to. Code smells popup in my head way sooner. While typing logic patterns that are common, my brain seems to be able to think across the entire program better rather than get caught up in the current file and program flow. All this probably because the brain doesn't need to constantly flit around telling me what key to press.
Because of all this, I tend to use keyboard shortcuts everywhere. Whenever I start using a new program regularly, I either memorize or create keyboard shortcuts.
Now, when people give me credit for being fast or more productive or knowing a language better, I think probably all of those things, even if true, would surely have taken longer if I didn't know typing.
I tell this to every beginning programmer. But sadly, till date, I've not seen anyone dedicate the time to learn this one skill that would help them in their careers, in their knowledge, in their life, in so many ways.
Steve Yegge in http://steve-yegge.blogspot.com/2008/09/programmings-dirties... where he also says
"And as for this non-college bullshit I got two words for that: learn to [explitive] type"
— Mr. Pink
And from Coding Horror (Stack Overflow co-founder):
We Are Typists First, Programmers Second
Is this why it seems that programmers never write comments these days? I feel like I'm the only one who uses a healthy amount of comments. But I'm also a very fast typist; I've been typing since I was 7 I think, and I can type fast both on QWERTY and Dvorak, and even switch seamlessly between the two layouts (I'm typing this comment in Dvorak). One of these days I want to try out Colemak to see how that compares; it'll probably be really easy for me to adopt it. So typing comments to me is very low-effort.
When I read your code three years from now, I can still figure out what it does. WHY you're doing the things you do is a different question. And few people leave them. Add them, and you're standing already heads and shoulders above your peers.
What are your thoughts on Dvorak vs. these other layouts?
Personally, my biggest gripe with Dvorak is that it bunches up all the vowels on the left hand home row, and it puts A on the left pinky, while U is on the index finger and I requires a lateral stretch. I do like how Workman sticks the E on the strongest finger, the right-hand middle finger. But the punctuation bothers me, and I feel like both it and Colemak make some sacrifices in the interest of not deviating too far from familiar-old Qwerty. As someone who's already proficient with Dvorak, I really don't care if a layout is "alien" to Qwerty users.
I've used a computer since I was 5 years old. I can type without looking. (I'm sloppy as hell though, since I was self-taught.)
But everyone I know types without looking.
At work, I'm using a mechanical keyboard with Cherry MX blue switches, to be (slightly) less annoying, but it's still a very different feel to it. These days, my only pain points are that getting natural scrolling outside of a mac is difficult (windows wants to keep resetting it back) and ubuntu removed it from the options, and it doesn't always work. And the ctrl/cmd characters on mac feel wierd... I've got cmd in lower-left and cmd at alt position, but in a console it's of course backwards in terms of muscle memory. And in mac home/end don't work as expected.
Not sure where I carried off into a hardware rant... but all the same, what you touch and look at are surprisingly important.
The first person that tells them is a curiosity, the second a fluke, and the third is on to something. If you're always the first person to tell them, you'll never see them heed your advice.
Also, whenever I watch a programmer use their typing skill, I can't help noticing that they use the backspace key almost as often as all other keys put together.
Oh, and one more thing: one of the best and extremely productive programmers I have known suffered from cerebral palsy. You can imagine that his typing skills were not very high.
As a software engineer, you need to evolve to adjust to the ever changing landscape that you work in. Whether it means learning the next evolution of the language you know (e.g. going from C++98 to C++11, 14 or 17), picking up a new library or even a new architecture (e.g. x86 to x64).
You must always be learning. Usually this means a lot of reading, some experimenting. But, the uniform constant is: learning.
If you know how to learn (and how this is done differs a lot between individuals), you have a shot at surviving as a software engineer. If you think you now know all you need to know and all you ever will know...well, you might as well inscribe your tombstone in the industry right now.
2.) Everyone here focus on teamwork, but I would add a bit opposite one too: ability to work independently for non trivial length of time.
Meaning: stays working and motivated without needing manager with all those sticks and carrots. Able to keep module clean without needing others to review it. Able to make decisions - whether architectural or time vs feature set ones or how to prioritize. We often socialize juniors to be completely dependent on elders giving them pretty much zero autonomy. They are smart and all that, but then fail the moment there is a lot work to do, detailed supervision is not available and they suddenly needs to make own decisions.
3.) Willingness to listen to other peoples ideas and thinking about them. Ability to distinguish between "bad code" and "different then what I would do". Seriously.
If it wasn't known about in 1980, and it wasn't published in a peer-reviewed paper since then, then it's probably not worth worrying about.
Plus, you can always take a few weekends to dig into the latest fad if you need to for a specific project and learn it quickly because you're not burned out by constantly scrambling from one technology to the next, trying to pad your résumé.
I think it's very important to master the foundations. In fact, I have a book from some anon. maths professors that say such and I was just reminded of it. They claim a student went from close to flunking to top of the class following their advice (interesting two professors provide that we evidence, however).
The book is called "5 steps to effective thinking" if anyone is interested.
Other then that, don't care about fads, general idea on what they are should be sufficient. Nobody cares that I did not learned CORBA years ago. Nobody cares I skipped browser differences between IE6 and Firefox something whenever that was actual. It does matter whether I can understand JS6 code reasonably fast.
We have to work longer and harder (into advanced age) these days to survive. While many people can learn and adapt and absorb for a long time, I don't think it's true that everyone is that way. Some people, as they age, have more trouble being able to constantly learn and instead end up "stuck" at a certain level of knowledge/skill/ability. In the world of tech where you can get flattened competitively speaking if you fall too far behind, it's incredibly difficult and can become infeasible.
Especially difficult if you end up going down the path of memory related diseases. For example, in my family we have dementia running in a few generations. The onset of dementia often shows itself in small ways far earlier than advanced age, for example, the inability to retain short term memory can kick in much earlier.
This is one thing that drove my feeling that I had to be as successful as possible and earn as much as I could when I was younger- not to be rich, but in case I literally was unable to keep the pace in the future.
But on the bright side, I have aspired to keep my mind open and learning as much as time permits, as the author discussed. So far, my colleagues have always told me they thought I was always a font of knowledge and I always tell them that it's only because I keep trying new things. Not because I actually "know" everything I talk about, just because I try to dabble and learn constantly.
I will say though, learning too much breadth, while really fun and a totally valuable way of learning (you start to see cross disciplinary patterns and connections between all kinds of things) - can lead you the "Jack of all trades master of none" conundrum.
A colleague once told me it is important that you are constantly working on something in your free time that is not something you do at work (eg. different technologies, different programming languages paradigm, different database type, etc).
This simple advice does two things: You are constantly learning, and you are making sure you're looking beyond whatever it is you are doing for money. You are widening your horizon. Maybe you discover something that you can eventually use at work, maybe it will never be useful.. Who knows in which direction we're heading?
I've started picking up hobbies unrelated to programming, it's much easier to spend the time learning something completely different.
I don't know how old the author is, so I have no idea what "5-10 years" means to him, but for anyone not at the beginning of their career I might add:
1) Add value well beyond any specific "engineering" you do. Beyond a certain point you will be valued for what you bring to the business; your coding mojo becomes less interesting to everyone as you get older.
2) Be good (get better) at the social part, including the boring meetings. Or make your "F-you" money in the startup world and do whatever you want... but if you don't do that, over time you will need to be good at the interpersonal side of the business you're in.
3) Don't treat #1 or #2 as excuses to stop caring about the code. Even if you make SVP and can't (shouldn't!) care about the company's code in detail, you should still care about your own, and about good code in general. Otherwise they will see your soul at the edges of your eyes, and it will be corrosive.
Like probably most of us, I need to work more on #2, and get better at explaining #1.
I do code every day, meaning 5-6 days a week; but I admit that I struggle to actually paint regularly (I am also a painter). Working on it...
I have bet on container orchestration and deep learning. Some people would say they are at risk of becoming a fad, but both have been used in solving previously seemingly impossible problems and are rapidly advancing.
And I think container orchestration will be a Thing for a long time to come, because it's such a pain in the ass. This will be a source of friction for years to come -- somebody set up the damn containers already -- so I think your choices look safe.
OTOH they might be wildly different skills, for better or for worse. The Deep Learning person is probably not going to be the Container Cluster Wrangler.
DS and Algorithms
Proficiency in one of the languages(C/C++,Java,Python)
Very good communication skills
The concrete answer is the cloud. Learn what serverless microservices are, how to build them, deploy them, and integrate them into a large system. Cloud devops is already growing leaps and bounds and just like we needed to know our OS in the past, we're going to need to know devops in whatever cloud we're using (AWS, Azure, Google, ???).
Learn Lambda's and functional microservices. Learn Paas and Saas, learn how to use a tool like DynamoDB even if it doesn't fit your prejudices for a data store.
Learn unit testing. You should be able to unit test and integration test using mocks in any platform you need to work in.
Agile project management. Sprint planning, planning poker, kanban boards, choosing tasks vs. being given tasks, retrospectives...these are all important to learn.
Keep some semblance of knowledge of metal. What I mean is, write some low-level code to understand how memory works, how things work internally within a platform. It's not important to be an expert, but understanding some of the nuts and bolts of software engineering will make you a better programmer.
Listen to everyone without prejudice. I can't say this enough. Everyone has ideas and even though new ideas may not make any sense to you, keep an open mind.
Be inclusive. Always try to make people around you better at their jobs.
Manage your emotions. You can be passionate and sometimes even obstinate about solutions, but manage how you interact with people. The greatest success comes from moderate temperament.
Coding AND explainibg really helped me to question my knowledge .
When I set out to describe something, I quickly discover how little I know about the thing. I then proceed to learn the missing bits. The time flows and when I finally feel I know enough the original problems seems too trivial to warrant a write-up... Or the post becomes many tens of thousands of words long behemoths that no one wants to read :(
Wikipedia says: WordPress was used by more than 27.5% of the top 10 million websites as of February 2017.
With so much agony to go around, ones ability to ease the pain will always be in demand... :)
- Static CMS Advocate - someone who explains that setup for a landing page with contact form doesn't need to consist of Nginx, Varnish, Apache, mariadb and redis.
I have been following Typescript and I increasingly believe that it will displace traditional backend web development, and we'll end up with Typescript on the backend and the front end. I think this because:
- it's a very modern language with great type features (it's clearly better than JS in my mind)
- it's got tooling support in all the major IDEs
- it's under rapid development
- it's being pushed ahead by Microsoft, and other big industry names
- it's been/being adopted by many projects, and it seems especially by people in the React space.
- Node is mature for server-side
If I was a Rails developer in particular) or a Python person who only does web (Python's not going away in scientific computing) I'd be keeping an eye on it. The way Typescript is going it may end up being a better, safer, faster language than Python , with the benefit of running in browser, on the server, and as a mobile app via React Native.
 this might be part of why Python is slowly starting to move on the typing front, but given there's still a lot of people on 2.x it'll be a while before progress is made. And it's only type hints, not enforcement.
For me, it's not painting, but playing music every day. I don't always get to practice, but the days that I miss are more likely be due to me procrastinating than to actual lack of time.
I also spend some time every day at work, doing some coding, even though I'm not employed as a programmer. Oddly enough, it makes me look quite busy, and nobody has ever questioned whether it's actually related to my job or not.
It's generally not difficult to do any given thing every day. It's difficult to do 20, though.
My point is just don't get comfortable with what you are doing. The "repeatable comfortable thing" you are doing today would become obsolete one day.
I mean, I solved more complex technical problems in my undergrad than I've ever had to in my career.
My suggestion: While you may want to master a technical skill or two, become good at what they don't teach you:
The Coursera course from the University of Michigan is decent, if you don't want to read. But the other course (from Yale?) - I would not recommend that as a starter.
(His work is often cited in other books - especially related to negotiations).
Finally, a word of advice. Most of us here on HN have no trouble reading stuff and grasping its content. Internalizing it, though, will take work. So don't run away reading all these books. Pick one topic (e.g. negotiation), and read up on it. Take notes (I forget 80% of what I've read after a few months). And try to practice it.
Life is a marathon, not a sprint. Just focus on one till you feel you are good at it (perhaps for a year). Then pick another topic.
Namely: the daily practice of doing what you do.
This can be any discipline, and it can be multiple disciplines for the same person.
It does look like there's a certain advantage to quickly learning the latest thing, but that's a job-hopper's advantage. I don't think the fast learning of fashionable things makes one a better or more respected engineer than the deep learning of useful things. (I admit there may be more money for job hoppers, in case that's the measure of success here.)
Success as an artist is a much more complex, chimeric thing than just creativity + marketing. But it doesn't happen without a lot of discipline, even if it's the same boring discipline one can achieve by going to the gym three times a week.
If you study the great artists throughout history, even contemporary ones, you see time after time the "1% inspiration, 99% perspiration" formula.
If you are talking about technologies, WebAPI is what all the kids are using these days, it's a more clever implementation than web services (WCF). Who knows what current saplings will grow. I usually don't pick something up until it's fairly well established.
More specifically you should look to balance out what you already know with something new. If you spend your weekdays making CRUD apps, don't spend your free time investigating (yet another) different way to make a CRUD app. Learn machine learning, operating systems, etc.
For an actual field, I would think anything to do with large amounts of data, whether it's machine learning, data visualization, etc.
Being able to work with your team effectively is IMO extremely important especially for engineers that jump around a lot to different jobs, teams and corporate cultures.
1. How to start a fire with flint and steel, or other technique without matches
2. How to purify water by boiling, iodine, distilling, etc.
3. How to build a shelter using a pocket-knife, some string, and an old tarp.
4. How to trap, kill, skin, dress, and cook wild animals
5. How to catch fish with a homemade hook, or with a spear
5.5 How to make a spear
And actually, when you think about it, all of those are things that very well could be valuable.
1. How to predict whether your neighbor will help you or try to kill you.
2. What to say to the Authorities when they find your prepper camp.
3. How to raise chickens in secret.
4. How to fully comply with all orders until you can make it to the border.
SQL. For the next 100.
P.S whoever thinks otherwise is an idiot and what's wrong with the software development world