Fads come and go and nobody cares about year old fad. It absolutely makes sense to learn anything that looks like a new concept you did not encountered before - it will make you able to learn faster in the future. It absolutely makes sense to learn whatever the ads ask for if you are look for job right now.
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.
If you follow this route, you'll have a lot of deep knowledge and the ability to pace yourself in your learning. I agree that that these things are both 100% more valuable than knowing the latest fad.
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é.
Out of curiosity, what are those concepts and papers you most recommend that fit this idea?
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.
As a counterpoint to learning something "new" every day, it might instead be wise to learn something you already know, but deeper, every day. As fields advance, the trend is towards specialization.
If they aren't already, expert-level skills in a few areas should be worth more than tutorial-level skills in a few dozen JavaScript frameworks.
I think what specifically you need to know about largely depends on the field you are working in.
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?
Sounds like a recipe for burnout. I've tried a few times picking up a new language in my free time, but since I program for work it made my days feel 3 hours longer.
I've started picking up hobbies unrelated to programming, it's much easier to spend the time learning something completely different.
So when I said "work on something not work related", I didn't necessarily mean "creating a side-business". It could also be studying or something. In my specific case, I try to study a specific subject each week, for which I invest 4h per week. In fact, it doesn't even have to be technical, I just try to focus on something rather than reading bits and pieces about everything on HN, Twitter, etc.
You make a fair point. I posted the opposite while you were writing this, but I could probably fit in 30 minutes a day. I'm just not sure how much I could learn in that little time - it can take me that long just to get into the right mindset.
I also had this problem of difficulty getting in the zone. I find that doing it constantly as a habit you get in the zone easily. Plus the knowledge will be stewed in your brain while you're at work. So you're not really only doing the project when sitting in front of the keyboard.
Its a pipe dream if you have a wife and kids. I get to paint every week if I specifically make time, but there's no way I could do side projects everyday and not burn out from doing nothing but work.
I have a wife, kid, and a whole mess of dogs. Job is fairly demanding and I have some other loose-ends from past projects that require some babysitting. I aim for at least 15 minutes per day in my wood shop, a little more on the weekends. It's enough that if I plan well, I can practice interesting things or make progress on projects.
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 possible, but you have to be disciplined. I try to get up an hour or two early every day at least for a week per month to put some quality time into the studies/projects. Other times it's 10 minute chunks that you squeeze in throughout the day which aren't productive.
It's hard to name one skill, but I'd put these into a single topic: the "soft skills" for becoming a more effective senior engineer.
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.
I came here to say this. So many of us focus on the technical advancement only. But learning to work with people becomes more valuable in the long run.
As far as specific tech, my crystal ball is a bit fuzzy right now but AI seems a decent bet.
Similarly, learn how to be a "force multiplier". Don't be the 10x engineer, but instead be the 10x multiplier.
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.
Leave them alone? I've always worked in "teams" where 1-3 workhorses made everything happen; the rest was talking, spinning intrigues and inventing new workflow procedures (which slowed down and annoyed the workhorses).
Have you ever seen a product manager or "the meeting guy" train juniors ? That doesn't even make sense, as you haven't hired those juniors to do either product management or "stakeholder management" or ... whatever the next fashionable term will be, so they simply can't provide the training that is needed.
At least where I work, the "workhorses" are the ones training the new guys.
I did and I was one of the mentee as an engineering lead. All I needed is to attend on meeting and listen or support the PM, but it was invaluable to see how to reason, convince stakeholders, gather requirements and objective feedback, and how not to give a fig to the emotions.
Not every problem has to be solved in team fashion and not every member of an organisation has to fit in a hiring pattern.
Also there are “brilliant jerks” or people with out-of-fashion worldview. These people could have their place in an organisation. Clearly this is a leadership challenge, but hey, leaders should learn hard and be great as much as their engineers.
Let's assume you have 3 engineers, one 10x and two 1x, their total output is:
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?
That's a very real possibility, so it's definitely something to be wary of and manage carefully, but if you adjust the made up math above to something more reasonable:
6x + 3x + 3x
Where your 10x reduces their own output to help the others triple theirs. This:
That's probably a better example... I consider myself a high output person, but that's usually offset by helping others, and part of my day "growing"... Most days I spend my pre-lunch hours reviewing emails, in meetings or reading things like HN articles. Afternoons I try to stay head down (headphones on) from 1pm onward.
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.
That effectively has happened at me at work - I volunteered to become a lead engineer, and have been thrust mostly into management. It has been a very enlightening experience, as I no longer am solving the difficult technical problems on a day to day basis (I maybe will solve one abnormally difficult problem every week), but I am now judged on the productivity of my team - I dropped my coding to near zero and focused on the soft skills & using my technical ability to help craft approaches for my team members to get to a more consistent level of productivity.
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.
If you really _are_ a 10x multiplier on a team, you should immediately quit and run your own show, because there's otherwise no chance you're being compensated remotely fairly -- nine times the sum of everyone else's wage.
If money were the only meaningful thing in life, you might have a point.
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)
Agreed. Some of the tech-oriented business conferences have talks I've found fairly helpful. E.g. talks on sales can be helpful, even if all they do is help you communicate better with other groups.
>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.
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.
I wasn't aware of the term, but I often give myself up to 2x the estimated time to do something... once I hit 150%, I'll do something less elegant that can move things forward and punt the issue for now.
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.
Bitcoin: nope [0]. Bittorrent: there's a huge ecosystems of clients written by different teams of people. Spark: do you mean Apache Spark? It has many contributors [1]. Tarsnap: is convenient plumbing wiring up S3 and the academic cryptography literature, neither of which are solo efforts. PGP: its most important manifestation is probably GnuPG, which also has several contributors [2]. Minecraft: Mojang has 47 employees [3]. I doubt Notch is the only person with code in Minecraft.
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.
But initial implementations are a single person, and yes, once they have greater adoption do grow... that said, there's still a lot to be impressed by in initial release.
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.
You can always try to work on projects, or portions of projects where your interactions can be minimized... You can be a contributor without having to have constant/heavy team interactions.
There are aspects of all of the above I tend to appreciate greatly, it really just depends.
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.
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 :(
I'd say most of the reading and writing of blog posts are in the "long tail" of people attempting to solve a niche problem in a technology they don't know intimately. Of course most of those are trivial if you already know enough to solve it, but that doesn't mean they're not useful. Extra points for including the conceptual explanation of why it is in fact trivial rather than just the practicalities.
I would say write it up anyways even if it seems trivial. Things that seem trivial to you could still really help someone out. Especially someone new to the problem.
As somewhat of a failure on this front, I think social skills are very underrated. You may be quite smart, but you know what ? Without a good network you're doomed. We as an industry might like to pretend it is a meritocracy but it hardly is (this from someone who spent a good deal of time in academia).
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.
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.
I haven't read this book but I listened to a podcast (Knowledge @ Wharton) where the author was being interviewed. It seems like it might be worth a read.
Application of Category theory and abstract algebra to Software engineering. Application of Category Theory and abstract algebra to API design and library design. Category theory -> composability on steroids.
P.S whoever thinks otherwise is an idiot and what's wrong with the software development world
Since stacks change and generally become more abstracted, i would say domain skills: Good ability to work with domain experts and deeply understand the domain and do it in a timely manner, write code as close to the domain level as possible, and having domain knowledge.
So my own anectdotal experience in this has shown the author's suggestions to be true. There's only one major catch that you don't start realizing unless it impacts you - your physical ability to actually absorb and retain continued constant learning.
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.
Let's formulate a skill-in-demand forecast based on Wordpress ubiquity, but sceptical.
I start:
- 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.
If you're a coder, and you have a job that lets you code (as opposed to sitting in a lot of meetings), then you already "paint every day". Side projects can be a useful way of learning new technologies, but if you're already spending 7-8 hours a day "painting" in work, how much extra skill will you attain doing more in your spare time?
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.
Not necessarily. You may be maintaining a J2EE app by day for a healthy wage at an established firm, and while you're coding every day, you're not "painting" every day. I think what the author is talking about is more than just writing lines of code, it's writing different and experimental lines of code, different from what you do for your day job.
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.
In general, I agree with this. But sometimes, one's job doesn't provide an outlet for one's passion. It could be because the technology is old, the libraries/tools are out-of-date/internal-only or simply because the work feels like a grind and doesn't lend itself to creativity.
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.
Exactly this. I grind on a massive codebase everyday and the time and risk involved in migrating to new tech would be far too great. Going home and spinning up a new project in some new language/framework is the only option.
8 years ago, I was working in a pretty massive codebase... I did two major refactors (both going into the wee hours of the night, so I could get it done without conflicting with others)... one was changing all date-time communications as well as ensuring all dates in the DB were UTC. The other was refactoring all of the logging within an application in the client and server-side.
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."
>There's no use cargo-culting the side project craze if it doesn't flow naturally.
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.
I am not quite sure where this requirement for Software Developer to work 8 hours with extra time because they are really motivated and then spend the totality of their free time on side project is coming from.
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.
> a developer setting a meeting to learn about a technical issue is frown upon
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.
You're probably working in the wrong places... I average about 2hrs a day of "learning" time... a lot of it on here, and reading related articles. Some of it updating software in github/npm. Bits of it exploring the db/codebase thinking of ways to improve things.
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 dedicate my pre-lunch time most days towards learning/reading... mostly blog articles, or touching something new. It tends to account for about 1/4 of my day, but allows me to be much more productive the rest of the time. I do another 4-5 hours a week on my own time similarly.
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.
162 comments
[ 5.0 ms ] story [ 232 ms ] threadIf 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.
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.
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.
https://www.amazon.com/dp/0691156662
If they aren't already, expert-level skills in a few areas should be worth more than tutorial-level skills in a few dozen JavaScript frameworks.
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.
It's generally not difficult to do any given thing every day. It's difficult to do 20, though.
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.
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.
As far as specific tech, my crystal ball is a bit fuzzy right now but AI seems a decent bet.
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.
[1] https://en.wikipedia.org/wiki/Bus_factor
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.
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.
"On the Myth of the 10X Engineer and the Reality of the Distinguished Engineer"
http://redmonk.com/fryan/2016/12/12/on-the-myth-of-the-10x-e...
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)
Some examples: https://www.findlectures.com/?p=1&type1=Conference&talk_type...
https://www.amzn.com/dp/B01LYRCGA8
>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.
https://en.wikipedia.org/wiki/You_aren't_gonna_need_it
https://blog.codinghorror.com/kiss-and-yagni/
Also, googling for links for YAGNI, TIL about:
https://en.wikipedia.org/wiki/MoSCoW_method
:)
https://en.wikipedia.org/wiki/Timeboxing
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.
[0] https://github.com/bitcoin/bitcoin/graphs/contributors [1] http://spark.apache.org/committers.html [2] https://www.gnupg.org/people/index.html [3] https://en.wikipedia.org/wiki/Mojang
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.
2. Work on resolving whatever issues led to the dislike of teamwork in the first place.
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.
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). https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
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.
Operating Systems
DBMS
DS and Algorithms
Proficiency in one of the languages(C/C++,Java,Python)
Very good communication skills
Coding AND explainibg really helped me to question my knowledge .
http://dev.to/kayis
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 :(
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:
Negotiation skills:
https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...
https://www.amazon.com/Bargaining-Advantage-Negotiation-Stra...
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.
Communication Skills:
https://www.amazon.com/Difficult-Conversations-Discuss-What-...
https://www.amazon.com/Crucial-Conversations-Talking-Stakes-...
https://www.amazon.com/Nonviolent-Communication-Language-Lif...
Influence:
https://www.amazon.com/Influence-Psychology-Persuasion-Rober...
(His work is often cited in other books - especially related to negotiations).
Networking:
https://www.amazon.com/Never-Eat-Alone-Expanded-Updated/dp/0...
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.
https://www.amazon.com/gp/aw/d/1119081459/ref=ox_sc_act_imag...
P.S whoever thinks otherwise is an idiot and what's wrong with the software development world
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.
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... :)
I start:
- 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'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.
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.
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.
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."
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.
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.
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.