[HN Gopher] What I've Learned in 45 Years in the Software Industry
___________________________________________________________________
What I've Learned in 45 Years in the Software Industry
Author : FauxDemure
Score : 667 points
Date : 2021-01-06 14:51 UTC (8 hours ago)
(HTM) web link (www.bti360.com)
(TXT) w3m dump (www.bti360.com)
| ncmncm wrote:
| All good advice.
|
| But all too often, the very best possible advice is, " _Get out.
| Get out now!_ "
|
| Get to a place where the Good Advice quoted above works. It can
| be _very hard_ to tell that, up front. You have to try and see,
| and plan to skip along if you guessed wrong.
|
| Most of my regrets, over 45 years in engineering, are over
| sticking around when what I had to offer was not what was
| welcome. Sometimes, what they needed, I didn't have. Other times,
| they didn't know what they needed, didn't want to know, and
| didn't recognize it under their noses. _Either way_ , you would
| much better be elsewhere sooner than later.
|
| For the young, it is tempting to try to prove your bosses wrong.
| _That never, ever works._ First, sometimes they aren 't. When
| they are, they will be committed to not seeing it. It is always
| overwhelmingly better to deliver solutions to people eager to get
| them. So, find those people.
|
| Often, you will have to prove yourself and the value of your
| ideas. That is not a reason to scram. But make sure before you
| start that success has a definition. "Ten times faster", "ten
| times cheaper", "ten times fewer server instances", "ten times
| less latency", "ten times less downtime" are hard to mistake, are
| remarkably often achievable, and are _sometimes_ welcome.
|
| In some cases, "two times" stands out; I recently got Quicksort
| to go twice as fast, and that drew some notice.
| zmmmmm wrote:
| > Clean, understandable, and navigable code and design
|
| It's interesting to see "navigable" in here - I've struggled to
| articulate in the past this problem and I think this nails it. We
| often see simplicity come at the cost of "navigability". All the
| configuration by convention frameworks have this problem
| particularly heavily. I'm often at a complete loss to trace the
| mechanics of what is happening in things like vue-cli, Rails /
| Grails, gradle, and many other dynamic frameworks.
|
| They achieve remarkable simplicity, yet I often end up hating
| them and swearing at them because I can't exercise my
| understanding of fundamentals to reason about them and
| rationalise what they are doing. "The database connection must be
| getting established somewhere - it should be traceable back from
| the point where the connection is used in some way" - well, no
| you may have to understand most of the entire underpinnings of
| the framework before you will achieve that understanding.
|
| I think this "navigability" idea really fills that gap well.
| Things should be simple, but they should always stay navigable
| based on fundamental knowledge.
| Arelius wrote:
| I agree, and I like the concept of "navigability". But I'm not
| sure I agree that many of the listed frameworks like Rails, are
| simple in my experience. There is a lot of "magic" complexity,
| but they just go through efforts to hide that complexity from
| you. It appears simple on the surface, but on deeper dive the
| complexity is still there.
| datenwolf wrote:
| With respect to
|
| > 1. Beware of the Curse of Knowledge
|
| I'd like to add, that knowledge can lead to "knowledge
| paralysis": The more knowledge and experience you have on a
| certain topic, the more problems and caveats you'll spot right
| away. Awarenes of those may prevent you from actually engaging in
| productive activity and instead tiptoeing around the problem at
| hand, instead of just implementing a "straightforward" solution
| (that ignores the 0.1% of corner cases, you know about, but won't
| have to care about).
|
| This is omething I'm struggling more and more these days.
| ChrisMarshallNY wrote:
| Cool article.
|
| That suit...that hair...
|
| He doesn't really deliver any "wise mountaintop guru" stuff,
| though.
|
| Just shows that good old-fashioned common sense is timeless (and
| distressingly rare).
| Ozzie_osman wrote:
| I loved the article too.
|
| I mean, the most important wisdom is never "mountaintop guru"
| insight, it's always simple things that just need to be
| reinforced and actually observed in practice.
|
| It's one thing to say "keep it simple" and a totally other
| thing to actually be keeping it simple for four decades :)
| breck wrote:
| > reinforced
|
| Agreed. I'm ~15 years in, and so even though I didn't come
| across any new ideas here, it's very helpful to hear what a
| 40 year vet thinks are the most important signals and try and
| harden those paths in my mind.
| Retric wrote:
| I have gotten a lot of advice but sage wisdom is rare. The
| closest I can think of is:
|
| "Expertise isn't coming up with the perfect solution, expertise
| is knowing you can get a good enough solution on time."
|
| Frequently you have a fast but risky option and a slow but
| guaranteed one. It's fine to work on the fast option, just
| remember to abandon early enough to still finish in time.
| chasd00 wrote:
| i can't remember where i read it but "engineering is the
| science of good enough" has always stuck with me.
|
| I'm reading Algorithms to Live By and the section on
| explore/exploit feels relevant here. At what point do you
| stop looking for new things and rely on the things you
| already know. lol I feel like i lack the IQ to connect all
| the dots but there's something applicable in that section to
| this discussion. maybe i should re-read it...
| uppsalax wrote:
| I loved the article! Thank you for sharing it.
|
| Even if I am moving my first steps into the industry (I'm a
| simple trainee at a Tech-StartUp and MSc student) I've already
| experienced many times the first point. I think trying to keep
| your feet (and mind) on the ground, even when you have a huge
| expertise is fundamental in communication, teamwork and goals'
| chasing.
|
| For example a friend of mine, graduated in one of the top
| programs in europe at Rotterdham Business School, has a huge
| expertise in the R language, he is able to manage data promptly
| at work, efficiently delivering in 2 hours what his colleagues do
| on Excel in the whole day. However he has big problems in
| communication here in Italy, he is not able to understand what
| other people with different background/expertise are asking to
| him precisely and this is becoming a huge issue in terms of
| career development.
| mr-wendel wrote:
| Stuff I'd add that I think is crucial, and all related to one
| topic: good writing!
|
| 1. _Learn to write specs_
|
| Call it an RFC, call it a PRD, call it whatever. Writing out a
| plan for any project taking around a week or more is always worth
| it. Use it to establish scope and priorities. Keep a "Questions"
| section that you whittle away at as you seek out feedback. Make
| the body a hierarchy of design tasks and implementation ideas.
| Track revision history and keep it up-to-date.
|
| You now have a great way to get sign-off from peers + management,
| an execution plan, a task breakdown for ticket management and
| historical documentation on what happened and why.
|
| 2. _Be terse_
|
| Is that email looking a little long? Write a "TL;DR:" section at
| the top and then see what you can delete. If it's nothing, leave
| the "TL;DR:". Otherwise you may find you've included a lot of
| intermediate thinking and people only need to know the
| conclusions.
|
| 3. _When learning something new, keep a dedicated list of "this
| looks like magic!" items_
|
| Use your "down time" to research items on this list instead of
| refreshing your favorite news aggregator. Ask your peers and
| mentors about them. Notice when tangental issues come up and
| spend a few extra minutes seeing how they're related and how that
| might yield some easier answers.
|
| 4. _When you want to ask for help... defer clicking "send"_
|
| Whether its an IM or email, write it up on the side first. Start
| with your question and follow-up with what you've already done to
| walk through finding the answer to save the person the effort of
| starting from step one or pointing out the obvious thing you
| overlooked. Often this will lead you to answering your own
| question. If not, still wait 15-30 minutes (if you can) before
| sending it and work on something else. In that time you're likely
| to think of something you overlooked and avoid interrupting
| anyone.
| yarinr wrote:
| Do you happen to know of a properly written (publicly
| available) spec? I'd love to see a good example.
| pionar wrote:
| I've always found the OAuth 2.0 spec [0] to be well written.
|
| [0] https://tools.ietf.org/html/rfc6749
| kmclean wrote:
| Not sure this is exactly what the commenter had in mind, but
| I think of Clojure's "design rationale" documents as good
| examples of thinking through a problem before executing. This
| is one for the language itself, but there are loads of others
| out there for other sub-projects.
|
| https://clojure.org/about/rationale
| dgb23 wrote:
| This is a nice essay introduction depending on the type of
| spec you want to write:
|
| https://www.joelonsoftware.com/2000/10/02/painless-
| functiona...
| mr-wendel wrote:
| I'm afraid not. The best I can do right now is offer an
| example outline of what I do. That said, if I'm working with
| a good project manager my format will differ: I'll focus a
| lot more on the technical details and leave all
| organizational aspects out (e.g. timelines, dependencies and
| impact on other teams, etc).
|
| The key principle is that _anyone_ (sales, marketing,
| support, product, etc) should be able to benefit from reading
| it and find it intuitive to see where you 're getting into
| the technical details and skip ahead to the next major point.
|
| 1. Overview
|
| A paragraph of two explaining the what and why of the
| project. Maybe some links to other related key documentation.
| Don't put anything technical here.
|
| 2. Change Log
|
| Bullet-point list of dates and major changes. Think of it
| like a git commit history.
|
| 3. Scope
|
| What systems are affected? Are there phases to the project to
| be called out? If its principally one system/repo/etc in
| question, what major components are changing?
|
| 4. Requirements/Tasks (the main body)
|
| Use a numbered list and aggressively refactor as you go so
| high-level items rise to the "left" and all related details
| are broken out as sub-lists. You can loosely think of it as
| something like "[section] > [epic] > [task], [task], [task]".
| Prioritize the list based on dependencies so you're always
| referring back to already-mentioned requirements instead of
| yet-to-be defined things.
|
| 5. Supporting Docs
|
| Put long-form examples, scenarios, diagrams, etc in their own
| section. Some people will only care about these, especially
| if they provide integration examples.
|
| 6. Concerns and Questions
|
| Ideally by the time a first draft is done this section no
| longer exists, but usually you'll find that you need to do
| research or get feedback from others to finalize the whole
| thing.
| Mauricebranagh wrote:
| I would also add use version numbering on all docs and
| properly minute meetings and action points.
| yarinr wrote:
| Thank you! this is helpful
| e-_pusher wrote:
| The operation manual of the original IBM PC from 1981 is a
| very good example.
|
| Personal plug: I wrote an article about writing specs a while
| back. I use the IBM PC spec as an example, so you might find
| my article useful.
|
| https://iskender.ee/2020/06/18/EE-Specs.html
| mr-wendel wrote:
| _" What even is a good specification, or the Huaqiangbei
| test"_
|
| Those three points are pure gold!
|
| I'd also add that you don't need to be working on a major
| project to benefit from standing back to writing it out
| first. Much of what I write is just a few pages, but it's
| still useful. It saves time overall, helps others get up-
| to-speed fast, and is fun!
| tristor wrote:
| > Do you happen to know of a properly written (publicly
| available) spec? I'd love to see a good example.
|
| As somebody that has written hundreds of specs and PRDs over
| the years, I think one of the counter-intuitive things about
| doing it well is that there is no such thing as a "properly
| written spec". Or more accurately, "properly written" isn't a
| single path. You can't really templatize this in a generic
| way.
|
| Instead, I'd offer the following basic advice which will help
| to build good specs:
|
| 1. Create an outline first, enumerate the list of
| stakeholders and the sections/topics that those stakeholders
| are most interested in addressing. Use this outline as the
| basis for filling in the details.
|
| 2. Don't write more than you have to. Rather than being
| overly verbose, establish the context of what/why/when at the
| top of the document in a summary, and then focus only on the
| most relevant conclusory details in each section after. The
| more shared domain knowledge the stakeholders have, the less
| you have to write.
|
| 3. A good spec results in a finished product/feature/widget.
| Be clear about what you know, what you don't know, and what
| you believe. Leave room for things to be discovered during
| implementation. Be concise.
|
| Basically, don't write more than is necessary to actually
| achieve what the output of the spec is trying to achieve
| given the team/organizational context that the spec is going
| to be used in. Be as concise as possible, eschewing verbosity
| when possible because shared knowledge already exists. For
| this reason, "properly written specs" are very
| team/organization/project/product/person dependent. There's
| no universal format that works.
| fjdjsmsm wrote:
| Why do all of the posts about the coup keep getting removed?
| sabhiram wrote:
| Uh oh, hug of death?
| trentnix wrote:
| 3. Simplicity Fighting complexity is a never-ending cause.
| Solutions should be as simple as possible. Assume the next
| person to maintain your code won't be as smart as you.
| When you can use fewer technologies, do so.
|
| This is the one I appreciate more and more as I age. Because
| frequently, I'm the _next person_ looking at my own code. And
| there 's no better gift to your future self than well-written,
| easy-to-understand code that is straightforward to maintain.
| ww520 wrote:
| Yes, simplicity is so important. I often adopt the stand of
| designing and writing software that I could forget. The intent
| is such that when I come back to the code I've written, it'd
| better be understood easily. That means keeping things simple,
| keeping things clear, keeping things consistent, and keeping
| things well documented. Simplicity helps a lot.
| astrobe_ wrote:
| I somewhat disagree with the way he connects simplicity and
| cleverness.
|
| I once had to explain the behavior of a particular subsystem.
| It was governed by a bunch of simple rules, but their
| combination created a complex behavior. This was similar to
| social insect colonies, where components (eg. ants) are driven
| by relatively simple rules, but the whole system exhibits
| remarkable "emergent behavior".
|
| What takes cleverness is to anticipate, predict,
| understand,explain the global complex behavior from the simple
| rules. If someone can predict what comes out from cellular
| automatons like in the _game of life_ , I am amazed. _Simple is
| not easy_ (no, sorry Rich, following your simple advice is not
| that easy either). Simple is not always easy to understand,
| even less so easy to do. That 's why complexity tends to
| accumulate.
|
| At the risk of being wronged, I would say that being
| comfortable with complexity is a form laziness. I belong to the
| messy type of person. I believe I am that way because I can
| rely on a good long term memory: because of that, I can yield
| to laziness and not put away things where they belong when I
| should. Being able to handle complexity is a great quality, but
| not being discomforted by complexity is like not being ashamed
| by your messy home.
|
| When you make the effort to really simplify, under the
| favorable circumstances (like in hobby projects, where you can
| afford to move goalposts a bit), you can make complexity
| collapse - not by its own weight, for once. I understand that
| the author emphasis teamwork and communication so he gives this
| kind of John Wood's " _Always code as if the guy who ends up
| maintaining your code will be a violent psychopath who knows
| where you live_ " justification for fighting complexity, but
| preventing complexity from collapsing by its own weight,
| crushing a product in the process, is to me on equal grounds.
| zmmmmm wrote:
| > I would say that being comfortable with complexity is a
| form laziness
|
| I love this, and your comment in general!
| koonsolo wrote:
| I came here to say the exact same thing, but I want to extend
| it a bit more.
|
| I've seen some developers, including myself, looking at some
| code and complaining "who the hell wrote this mess!", only to
| find out in repository history it was themselves. lol.
| trentnix wrote:
| ...every day of my life!
| jjice wrote:
| At a previous job, I was the only person to document
| architecture structure and design choices in a document in each
| repo I worked on. They turned out to be very helpful for the
| new employees we took on over my time there. While that's a
| great plus, the real reason I wrote those was for myself
| because there is no way in hell I'll remember how to deploy
| this app to a new EB instance.
| trentnix wrote:
| That describes my motivation for writing documentation
| perfectly.
|
| In my last job, I wrote documentation so I could quickly get
| back into the context of the different problems I was working
| on. Context switching was a real challenge in that
| environment and I referred to my own documentation
| frequently. And sometimes, writing documentation helped me
| better understand the problem I was working similar to the
| idea that teaching a topic is a great way to learn.
| castlecrasher2 wrote:
| >Assume the next person to maintain your code won't be as smart
| as you.
|
| It's especially easy to assume this because I've often gone
| back to code I made a year or even months ago and barely
| understand it.
| ahstilde wrote:
| I've always heard great things about working at BTI360. Two of my
| friends have had long tenures there (long for software
| engineering, at least).
| cmrdporcupine wrote:
| This is very wise:
|
| "When I was at GM, you were a failure if your next move was not
| up--managing more people or taking on bigger, more complex
| projects. For many, this made for a miserable career path"
|
| As I've said before, I think this is a corrosive aspect of the
| perf/promo process at many FAANGs. The "level" system
| encourages/pushes people to "upgrade" in this manner, and I think
| contributes to a number of problems. For one, organizational
| incompetence when people who were valuable contributors where
| they were are elevated up into roles where they no longer can
| apply those skills as effectively (i.e. technical team lead to
| management or architect) leaving a vacuum below. A form of the
| Peter Principle I guess, except the individual may have
| competence in their new role but not be happy, or make the team
| itself less successful.
|
| And most importantly, as he touches on: being asked to 'level up'
| and told that this is your mission can lead to an unpleasurable
| career. Either when you do get that promo and then find that you
| don't enjoy the new responsibilities (but become trapped by the
| position / upgraded compensation etc.) or when you don't get the
| promo (or don't try) and find that your value in the eyes of
| yourself and others seems less.
|
| And finally, I think this type of thing can really take hold in
| places with a highly academic background / focus / origin (like
| Google, etc.) as it mimics in many ways the grade / peer review
| achievement structure of academia. And that reward / grading
| structure may not at all correspond to either the monetary or
| cultural success of a corporation.
|
| Smaller companies looking to grow/formalize should exercise
| caution when looking at the rating/performance/promo process @
| FAANGs / MS as a model for their own.
|
| (I'm at 20-25ish years in the industry, but really feel junior in
| so many ways when I read the words of veterans like this.)
| justinwp wrote:
| Having been employed at Google for about nearly two years, your
| take doesn't seem accurate at all.
|
| > And that reward / grading structure may not at all correspond
| to either the monetary or cultural success of a corporation.
|
| The key feedback/suggestions I see for my own performance
| review is to define my impact on both the monetary and cultural
| success of my org. Exactly the opposite of what you are saying.
|
| > being asked to 'level up' and told that this is your mission
| can lead to an unpleasurable career
|
| I don't see this happening either. I commonly hear others say
| the opposite and make it known they are no longer trying to
| level up and that they are happy where they are.
|
| > technical team lead to management or architect
|
| This does not jive at all with the various career ladders I
| see. There is no ceiling that requires me to move to management
| in my tech ladder.
|
| > find that you don't enjoy the new responsibilities
|
| To some extent, the promo process levels up employees already
| working at that n+1. Sure, some may not want to maintain that,
| but that is ultimately up to the individual.
|
| Disclaimer: I work at Google, opinions are my own.
| cmrdporcupine wrote:
| I also work at Google and in my 9 years there I've never had
| a perf process where monetary or profit-success goals of the
| company were mentioned once.
|
| EDIT: I guess when I worked in ads, there were ad performance
| type metrics discussed to some degree. Not much though.
| justinwp wrote:
| Goes to show how diverse a large company can be even with
| the same underlying processes.
| cmrdporcupine wrote:
| I think there are product areas in the company that lend
| themselves more to this, for sure.
| ThrowawayR2 wrote:
| > " _to define my impact on both the monetary and cultural
| success of my org_ "
|
| What you get out of that is people frantically chasing impact
| and visibility instead of focusing on the humdrum drudgery of
| keeping the lights on. The result is penny wise and pound
| foolish behavior that definitely does not correspond to the
| monetary or cultural success of the corporation. People who
| are good at gaming the system in this can create their
| "impact", collect the rewards, and make an internal transfer
| before the costs or superficiality of their "impact" catch up
| with them.
| mathattack wrote:
| Yes. The challenge is how to measure individual contributors.
| It's easy in Sales, which is why salespeople can do very well
| without being managers. Harder with engineers, whose work is
| very interconnected.
| guytv wrote:
| Team mates, usually know who is a good engineer, and who's
| not - much more accurately than management. When I was in
| Google, Perf process was based on peers feedback, and it
| worked well.
| mathattack wrote:
| How much variable in rewards and comp are based on the peer
| reviews?
|
| Another challenge with large firms is the overall lack of
| variance.
| cmrdporcupine wrote:
| For sure. And it's why frankly in my opinion it's very hard
| to scale software development effectively beyond 25-50
| engineers. After that politics and faux-meritocracies take
| over as people lose personal touch with each other.
|
| Not that small companies can't be hell, too.
| mathattack wrote:
| Yes. Most good people know who the other good people are,
| but it's hard to turn that into a plan fit for large
| companies.
| barnacled wrote:
| There is a corollary to this - having a career of sideways
| moves and simply not progressing even in ways that are positive
| and to your liking because each move effectively puts you back
| to zero and companies taking advantage of the 'flat structure'
| myth to avoid having to provide career progression.
| Accujack wrote:
| Expecting a talented software engineer to "upgrade" to become a
| manager of a development team makes exactly the same amount of
| sense as expecting a talented accountant to gain a bit more
| skill and suddenly become a lawyer.
| bjornsing wrote:
| That's a really weird analogy... Writing software (in any
| reasonably challenging context) is not administrative grunt
| work with clear and easy definitions of right and wrong.
|
| It's an art and a science. So I much prefer the comparison
| with pro athletes who become coaches or actors who become
| directors.
| watwut wrote:
| But also, the non technical managers I have seen were mostly
| toxic. And none of them were good - not even those who were
| decent people.
|
| It is not that all or most engineers would be good manager,
| but without that background you are guaranteed to not be
| good.
| karmakaze wrote:
| It might be closer to a pro athlete retiring from playing and
| going into coaching, but not so many would be good in that
| role.
| rjsw wrote:
| Almost all football managers are ex players.
| [deleted]
| brummm wrote:
| Just for fun, I checked for the German football league. I
| think more than 3/4 were professional football players
| before becoming coaches.
| jedberg wrote:
| Well, only 1/3 of them played Pro before going into
| coaching. The rest were college players (and two only
| played in High School) who switched to coaching, mostly
| because they didn't get drafted.
| cambalache wrote:
| Only for a very broad definition of "ex player".
| Mountain_Skies wrote:
| Yes but most ex-players are not football managers.
| rileymat2 wrote:
| This is interesting I did a bit of Googling, I guess it
| varies by sport quite a bit. https://www.post-
| gazette.com/sports/around-the-league-nfl/20...
|
| Some sports, most coaches came from players, but the NFL
| notably does not.
| bradstewart wrote:
| I wonder if team size has anything to do with that.
| Football teams are much larger than those in other
| sports.
| karmakaze wrote:
| Also the division of roles is far more specialized than
| say basketball. Only the QB might have a near/full
| picture.
| skrtskrt wrote:
| Linebackers, as the captain of the defense, which
| requires a deep understanding of the offense as well,
| tend to end up coaching as well.
| nkassis wrote:
| Football team coaching staff are almost like another
| team. Position coaches usually are ex players of that
| position but as you move up the chain it gets more into
| strategic management and thus by the HC level it's more
| of a manager role with architects underneath for offense
| and defense so less position technical knowledge more
| game knowledge.
| mrfox321 wrote:
| I wonder if brain damage/CTE has something to do with it.
| acheron wrote:
| In baseball, coaches and managers are all ex-players, but
| not necessarily _good_ ex-players. (Well, anyone who
| plays in MLB is "good", but relative to the rest of the
| league I mean.) Just like in other industries, the skills
| required for a good coach or manager don't always
| correlate with being the best player.
| marcosdumay wrote:
| "Most coaches came fro players" is very different from
| "players are expected to become coaches".
|
| I can't think of any sport where players are expected to
| become coaches.
| Leherenn wrote:
| Football/soccer? Of course there are more players than
| coaches so they can't all become coaches, but I would say
| star players are expected to become coaches, and lots of
| them do.
| Alex3917 wrote:
| > I can't think of any sport where players are expected
| to become coaches.
|
| In amateur sports it's common. E.g. in rowing, cycling,
| fencing, cross country skiing, etc., people are generally
| expected to coach at some point. Albeit usually while
| they're doing the sport, and not necessarily as their
| primary careers.
| phamilton wrote:
| Yeah, but this might be closer to "actors are expected to
| wait tables". It has more to do with paying the bills
| than career advancement.
| jayd16 wrote:
| In my mind its not that far fetched, depending on the person.
| The transition from experienced dev, to mentor to leadership
| doesn't seem all that unnatural.
|
| Not everyone wants that though.
| cmrdporcupine wrote:
| There are other paths at Google than upgrading to mgmt, but
| all of them involve "cross-team collaboration" and other
| quasi-political (with a small-p) aspects.
|
| Actually just writing code at Google is, from my experience,
| a small part of the job and not rewarded. The faster you get
| out of writing code and get into designing and delegating it,
| the better you're off. Sucks if you don't like it.
|
| Coming up with a way to reward and improve nose to the
| grindstone technical contribution seems to me key to having
| an effective organization.
|
| EDIT: also consider, doing management or team lead at a
| company like Google is so different from, say, a small
| company, that the trajectory may make no sense for somebody.
| Before I came to Google I felt myself on a career track that
| was team-lead/architect focused, mgmt interest, etc. Once I
| got there, that evaporated. I just couldn't imagine myself
| doing that kind of work in this large of a company.
| mcguire wrote:
| Over the course of a number of years and a few jobs at IBM
| starting in the early 90s, I knew 2 people on their
| "technical track". Their jobs involved _huge_ numbers of
| airline miles, continual meetings, and essentially no
| technical work.
|
| That was one of the primary reasons I stayed a contractor
| most of my career.
| cmrdporcupine wrote:
| Interesting that your contractor jobs haven't also filled
| with non-technical, biz type work? Lack of desire to deal
| with accounting, client meetings, all the organizational
| aspects of running a business have kept me away from
| contracting or consulting.
|
| Might be time for me to revisit that, this being the year
| when I really think I need to start something new. I have
| no idea how to make that switch though.
|
| Are you contracting through your own business, or someone
| else's?
| breck wrote:
| In the 2000's I did contractor work by myself (and
| occasionally hired a friend or two to get a project
| done). It was a disaster. I spent >50% of my time on
| client, non-technical work. I then joined a ~20 person
| firm in San Francisco and worked there for a few years
| purely coding. It was a joy. They had great business
| people, designers, copy writers, and then about a dozen
| great engineers, and I could just focus on the code and
| get paid for that. My hours went down, pay went up, and
| got to do what I love.
|
| If you are thinking of contracting/consulting, I'd highly
| recommend joining a diversified team in the 10-100 range
| so you can do the parts of the work you love and rely on
| your team for the rest.
| mcguire wrote:
| Yeah, I no interest in running my own consulting
| business.
|
| In my case, it was usually a contracting company with
| 10-100 contractors working for one or more client
| companies, but the contractor had 0 day-to-day influence
| on the work I did. (I did try to pick up my paycheck in
| person and chat with the office staff.)
| 8ytecoder wrote:
| If it's anything like my experience hiring contractors,
| it's definitely that they get the most "fun" part of the
| work. Most companies use contractors (in engineering)
| precisely for a well-defined tech work. They don't have
| to manage people or sit in meetings that are not
| relevant. We pay them by the hour and we try to get them
| to work on the stuff they can contribute the most -
| dealing with politics is expensive.
| mcguire wrote:
| Typically, no. I almost always worked as an employee of a
| technical contractor---I was an IRS W-2 employee; they
| withheld taxes and provided (sometimes decent) health
| benefits (although I decided it was better to buy my own
| rather than changing insurance when I moved). I had no
| more than the usual accounting and organizational
| challenges.
|
| For me, getting into it was easy. I packed off a resume
| to several of the local contracting companies. They pass
| the resumes to the ultimate company, who will do an
| interview (usually very low stress because it's easy to
| get rid of you) and then the contracting company and the
| employer work out all the details. (It may have changed,
| but at the time of my last such deal about 2005, the
| contracting company absorbed about 15% of what the end
| company was paying for you.)
|
| Do realize that you need to keep at least 6-9 months of
| your income in a readily accessible account (savings,
| money market, or (whoo, I'm old) CD). I never went for
| more than a week before I could another job, but I have
| known people who had more trouble.
|
| I have since gone into federal government contracting,
| which is another whole bag of stinky fish heads.
| saberdancer wrote:
| I've moved into contracting after being a software
| engineer/developer/team lead.
|
| Essentially since you are contracting, you are outside of
| the "bubble" where decisions regarding business get made.
| So while you may have important work on the project, you
| are not there when they are deciding on business aspects
| of it, you are usually not invited to any type of sales
| meetings or meetings with the clients. This is reserved
| for company people.
|
| Another aspect you can do is that you can outright reject
| that type of work or slowly move away toward a client
| that is not requiring that type of work. When you are
| working in a company, you usually do not have power to do
| that. Your only option in a company is usually to quit
| and then hope next company doesn't pull you into that
| meatgrinder.
| mcguire wrote:
| This, exactly!
|
| The down side is that you don't have any direct influence
| on those business decisions. (At one point, I wrote about
| three different login/single-sign-on clients for a web
| app infrastructure (including Kerberos/Active Directory)
| before they finally decided that SAML2 was
| politically/technically the right choice. Frustrating.)
| You do have indirect influence if you have a good
| relationship with your team lead, who will likely be a
| "real person", a real employee.
| spicymaki wrote:
| Personally I "think" I want to just code forever, but I
| migrated from coder to more of an architecture role.
| However, for me, the growth is just not there. It is in the
| cross-collaboration, mentoring and industry influence is
| how you develop. In some companies time in grade is a
| factor in layoffs. Due to ageism companies might not be
| looking for someone at a certain age and experience to just
| grind out code full-time, but to work on a product
| holistically.
| coding123 wrote:
| I've seen people from small companies playing the tech lead
| or manager roles, move into google as "Senior Software
| Engineer" or whatever equivalent - basically writing code
| again. And the reason is in your edit. In fact a lot of the
| "hot shots" at small startups that play nice with the boss
| and can wrangle Jira but were actually excellent coders -
| can't do the politics at the big companies.
|
| Part of that is that the big companies typically hire suits
| to do management - which were basically the jocks in high
| school that always got the girl... that type - they run
| everything in the world now. Loud mouth tech bro asshole
| types.
| randomdata wrote:
| The only difference between a manager and the other on-the-
| ground engineers is that the manager works more closely with
| the stakeholders to understand their requirements in more
| detail than the other engineers have time to. With that
| additional knowledge in hand, the manager helps guide the
| other engineers to make the right tradeoffs. It is still
| engineering, just at a different level. A level not everyone
| enjoys working at, granted.
|
| I guess if there is an accounting analogy, it would be
| selecting one accountant to work closely with the government
| to ensure that the tax law is fully understood and to watch
| the other accountants to ensure that they are following that
| tax law, reducing the inefficiencies of all the accountants
| in a firm needing to spend their days acquiring a perfect
| understanding of the tax law and not spending their days
| doing the practical accounting work.
| worik wrote:
| Best manager I ever had was a engineer.
| duxup wrote:
| First real job I had there was this guy who had one
| specialization. He was in charge of some software that drove
| tape drives.
|
| Every outside new manager would come in and in some form or
| another look down on this guy in some form due to his age and
| generally not doing "a lot" of tasks and new products.
|
| It took the local VP to come down and regularly high five him
| after his product git rave reviews from customers (regularly)
| and make the point every time some manager didn't get it.
|
| That guy's code, documentation, everything was rock solid, and
| the number of support cases for everything he did was so low
| that the dude was without a doubt the most productive person as
| far as income goes. You could sell the product that he worked
| on and just rake in money with almost no costs after that.
| Almost everything else had a lot of support costs and etc.
|
| Meanwhile the guys who were doing all the new stuff, sucked at
| trying to juggle 12 things because it looked good on a resume.
| riku_iki wrote:
| That guy could perfectly be some tech lead, establishing his
| rock solid approaches on team of junior 4-10 engineers and
| delivering rock solid new products.
| duxup wrote:
| I didn't say it outright but I picked this guy as an
| example as ... hey ABSOLUTELY did not want to lead anyone /
| should not lead anyone.
|
| Very much the high performer type who SHOULD NOT 'progress'
| to management or supervisor or ... reviewer of any sort.
|
| He was professional, but "prickly". I found the keys to get
| along with him but a lot of folks didn't have the patience.
| riku_iki wrote:
| If he doesn't want, it is one story.
|
| Another story may be because he may not be promotable to
| such position because of mentioned "prickly" behavior,
| which may or may be not just engineering honesty and
| straightforward approach in contrast to bs(sugarcoating,
| ass kissing, exaggregating, sweeping dirt under carpet,
| etc) culture established in many companies.
| jdbernard wrote:
| Not everyone has the disposition to teach and lead.
| sli wrote:
| Before we even get to disposition, some folks simply do
| not want to do those things.
| noir_lord wrote:
| It's similar to the systems administrator dilemma.
|
| Do your job well, it looks you are not doing very much, why
| are we paying you?
|
| Everything is on fire, it looks you are not doing your job
| properly, why are we paying you?
|
| I've worked with a few engineers over my career like the
| person you described and frankly they are worth their weight
| in gold, been able to bank on their output working reliably
| and consistently over time is hugely valuable, doubly so when
| what they do is the bedrock of many other things.
|
| Of course the unhurried, thoughtful person looks like they
| are slacking and the hurried, frantically working person
| looks like they are a hard worker.
|
| Fundamentally it's because impact is harder to measure than
| perception.
| ddingus wrote:
| It just occurred to me a sysadmin log would be very
| valuable:
|
| Installed update X to prevent risk Y
|
| Wrote script to advance process Z on input A
|
| Etc...
| justin_oaks wrote:
| As a sysadmin, I actually keep a log, but I'm under no
| illusions that anyone will ever see it but me.
|
| I used to track my tasks in Jira with the thought that
| maybe my boss would look at it and see what I was doing.
| Of course he wasn't looking at it so I stopped doing it.
|
| My log is mostly for me to provide a list of achievements
| to my boss whenever there's a review, or if I'm
| questioned about what I spend my time on.
| ddingus wrote:
| I did too. But I never did connect the value points to
| the admin activities.
|
| If I sysadmin again, I am going to do that. "Why those
| trains ran on time."
| dsr_ wrote:
| I ask my junior sysadmins / new hires to write a daily
| log for their first year or so.
|
| What did you do today?
|
| What do you need help with?
|
| What went well?
|
| What was frustrating?
|
| What should we change or fix?
|
| When we get together to talk about their day or their
| week, these logs are extremely useful. Sometimes they
| generate tickets, sometimes book or course
| recommendations, people to talk to, sometimes just
| conversations.
| kstenerud wrote:
| I've been bitten by this.
|
| I once worked at a place where the development process for
| the Windows version of their product was GLACIAL because
| there was no way to run the CI scripts locally or even set
| up a dev environment that could build the product. People
| actually edited code in a text editor and then submitted it
| to github and waited an hour for the CI job to build a
| virtual Windows instance, run updates, install Visual
| Studio, Oracle, and all supporting software, run the
| compile and bail with a syntax error :((((((
|
| So I made a Powershell script to install everything from
| scratch on a fresh Windows 10 or Windows Server system
| using Chocolatey. The script took about an hour to run, but
| once it was done you had a Windows box (or VM) that could
| build the project in 2 minutes at most, or just run the CI
| script directly before committing. Suddenly it didn't take
| weeks to fix bugs in the Windows client, and corrupted
| installs or DLL hell was one "wipe", "run script", "walk
| away while it churns for an hour" cycle to a perfect dev
| environment again.
|
| I was fired 6 months later for "not stepping up enough".
| withinboredom wrote:
| I lived almost the exact same story. Except when I was
| fired I was told to go work at a bigger company. So I
| did.
| sroussey wrote:
| Management should clearly see impact and that your work
| multiplier is higher. Their loss for sure.
|
| Typically, higher leveled engineers have higher workforce
| multipliers --- their output is measured not only on
| their own work but how they move the whole team,
| division, company, or industry forward.
| tnr23 wrote:
| Tbh your achievement sounds like you added a lot of
| complexity (treating symptoms) instead of really trying
| to tackle the core of the problem.
| castlecrasher2 wrote:
| I'd like to hear an explanation for what seems to be an
| awful take. Why do you think this?
| Buttons840 wrote:
| > Do your job well, it looks you are not doing very much,
| why are we paying you?
|
| > Everything is on fire, it looks you are not doing your
| job properly, why are we paying you?
|
| Option 3: Everything is on fire, be really quick to respond
| to your manager and then poke and prod at things in
| production until it kinda works, repeat daily. This guys a
| hard worker! I'll have to keep him in mind for a promotion.
| larrik wrote:
| On the other hand, lots of places have people who they
| _think_ are this guy, and who are actually just a bad dev
| who is good at building an impenetrable moat for job
| security...
| freedomben wrote:
| > _Fundamentally it 's because impact is harder to measure
| than perception._
|
| Absolutely. Another nontrivial variable is the tendency for
| managers/team leads to get the "credit" for successful
| work, even if they aren't trying to.
|
| I've had managers before that did nothing but impede a high
| performing team. Luckily we delivered despite this. But it
| never failed, the manager would get accolades (often very
| public) for successfully releases, customer feedback, etc,
| and would end up promoted up. Meanwhile the team kept doing
| our thing, getting barely-matches-inflation annual
| increases and more and more micromanagement from the scrum
| diehards. Didn't take too long for the team to move on to
| better things. I have a dream of someday reuniting the
| super team for a sweet startup idea. Not likely to happen
| but I can dream :-)
| sroussey wrote:
| Shoot me the list of these team members. :)
| sli wrote:
| > Meanwhile the guys who were doing all the new stuff, sucked
| at trying to juggle 12 things because it looked good on a
| resume.
|
| This isn't helped by the current trend of trying to hire
| mostly fullstack developers, also known as hiring one person
| to do the job of three people. It does almost nothing but
| incentivize packing resumes to hopefully make the cut and
| burn people out from switching modes.
| watwut wrote:
| Fullstack does not mean that you will burn out. Fullstack
| can mean 40 hours a week, never overtime. Also, for smaller
| apps, after you had at least few months of experience with
| all technologies, it is not difficult to switch modes.
|
| People who specialize will be better at their
| specialization, but you will be good enough for majority of
| apps.
| lolive wrote:
| The JavaScript fatigue is NOT a myth. [and CSS/layout is
| really tough, too]
| marcosdumay wrote:
| All of that applies to frontend development too.
|
| At the end of the day, some people like Javascrip and
| CSS. And "full stack" only means that they will work with
| those, SQL, and some backend language (that may be
| Javascript too). It doesn't imply anything on the
| workload, all it does imply is that the place is hiring a
| generalist instead of specialists.
| irrational wrote:
| I think of it as vertical vs horizontal career path. Vertical
| is becoming a manager of more and more people and/or projects.
| Horizontal is becoming an expert at more and more
| technologies/languages/etc.
| Gibbon1 wrote:
| > Smaller companies looking to grow/formalize should exercise
| caution when looking at the rating/performance/promo process @
| FAANGs / MS as a model for their own.
|
| Robert Townsend had a comment that stuck with me, you don't get
| to be GM by behaving like GM. Which is beware of cargo culting
| successful organizations as they exist now. I'll also suggest
| don't cargo cult hyper funded startups if you aren't one
| either.
| macjohnmcc wrote:
| I'm happy to lead as long as I also am allowed to work on the
| code itself from design to actually writing code. I have been
| doing this full time for 35 years and I would be miserable had
| I switch to a pure management role at any point including now.
| Meetings kill motivation for me.
| cletus wrote:
| > As I've said before, I think this is a corrosive aspect of
| the perf/promo process at many FAANGs.
|
| So I have to ask: do you or have you worked at a FAANG with
| these systems? I may be wrong but I suspect you haven't,
| particularly if you're equating them with more traditional
| hierarchies.
|
| The whole point of a system like this (and I have direct
| experience at Google and Facebook) is so you can go pretty far
| as purely as an IC. You're not forced to become a manager.
|
| So at Google for example, new hires start as a T3 (T4 for
| PhDs). There is an expectation for growth up to T5, meaning
| technically you are meant to progress over time. When I was
| there this wasn't strictly enforced (eg I knew people who had
| been T4 for 5+ years) but it may vary from PA to PA or manager
| to manager and it may well have become stricter.
|
| IIRC the general guidance was 2-3 years T3 to T4 another 2-3
| years for T4 to T5.
|
| At that point you can sit at T5 forever if that's what you want
| to do. People's desire to get promoted leads them to becoming
| managers because it is demonstrably easier to promoted from M1
| (T5 equivalent) to M2 as en EM than it is from T5 to T6 as an
| IC.
|
| These higher levels are really an indication of your
| organizational and technical impact and for this you really
| have to influence others. This is not being a people manager
| however.
|
| But the point is that there's no "up or out" (beyond T5) like
| you may find at IBM or KPMG.
|
| Now there are definite issues with Google's approach here and
| that's really a whole other topic. I just don't think your
| observations here adequately describe the FAANG career paths
| (IMHO).
| wool_gather wrote:
| > new hires start as a T3
|
| This makes me curious about what T1 and T2 would mean.
| closeparen wrote:
| Blue collar IT. Racking and stacking, help desk, event
| space A/V, wrangling desktops and phones, installing WiFi
| access points in the office, etc.
|
| Tech companies don't pay particularly well for these
| things, but their benefits packages are very competitive.
| namdnay wrote:
| Maybe non-engineers?
| mosdave wrote:
| I'm more curious about why a new hire with 20 years of
| experience starts at T3.
| cletus wrote:
| Yes, sorry, I worded that poorly. I really mean "new
| graduates (non-PhD)" not "new hires". Apologies for the
| confusion.
| hengri wrote:
| they dont
| cletus wrote:
| The SWE (Software Engineer) ladder doesn't have levels
| below 3 (AFAIK). Other ladders do.
| closeparen wrote:
| The senior IC ladder saves you from being responsible for
| people, their job satisfaction, their career progression. But
| it is still a kind of management.
|
| Facilitating meetings, reviewing documents, tracking
| schedules, reporting progress, convincing teams to prioritize
| the work, negotiating with those challenging the technical
| decisions, securing credit, deflecting blame, getting
| resources, etc. The model of an effective L6 or L7 IC is part
| secretary, part Frank Underwood.
|
| You're right that you don't have to pursue L6/L7, but L5 is
| attainable in < 4 years. No 46 year old wants to be doing the
| same thing for the same pay as a 26 year old.
| cmrdporcupine wrote:
| > No 46 year old wants to be doing the same thing for the
| same pay as a 26 year old.
|
| <foghorn-leghorn>I say, I say, I say boy, I resemble that
| remark</>
| cletus wrote:
| > No 46 year old wants to be doing the same thing for the
| same pay as a 26 year old.
|
| Why not? Being a T5 SWE at Google is (or at least it can
| be) pretty chill. It's a sweet spot for low stress and
| relatively high compensation. Why exactly do you need to
| "advance" your career, particularly if you don't want to be
| actually or effectively managing other people?
|
| The alternative is the "up or out" approach that drives
| engineers in other industries into being (usually bad)
| managers.
| cmrdporcupine wrote:
| L5 / "Senior Software Engineer" expectations are such
| that you have to have "influence beyond yourself", own
| some area of work, set technical direction for some other
| engineers. You're either a team lead or an "exceptionally
| strong individual contributor".
|
| It's not really that chill, and if you don't continue to
| do those things (lead or be exceptionally strong) that
| will show on your perf and therefore your compensation.
| Going from L4 to L5 means committing yourself to doing
| that on an ongoing basis. Remember at Google that
| "consistently meets expectations" is only a 2 out of 5
| rating, just above "Needs improvement."
|
| Coasting at L4 ("SWE III") could be fine. Large
| independent technical contributions, manage your own
| priorities, participate in design, etc. Solid individual
| contributor. Really equivalent to "senior developer" at
| most other jobs.
|
| But now let's say you want to go transfer to a new
| project. The manager on the other team sees you've been
| at Google many years, but still at L4. Hm. Results may
| vary.
|
| Not everyone makes a good team lead. Especially in a
| place like Google surrounded by PhDs and super achievers.
| But the expectation at Google up until very recently was
| basically that you should become that, or get out. Now in
| the last few years, it's been stated it's perfectly fine
| to plateau at L4. But I'm not convinced that that's the
| reality of the culture or expectations of managers.
| cmrdporcupine wrote:
| > So I have to ask: do you or have you worked at a FAANG with
| these systems?
|
| Yes, 9 years at Google. But yes, not experience beyond the
| L4/L5 tier.
|
| It is true that the IBM type structure isn't the same, and
| yes, Google is fine with you staying around L5 forever (well,
| L4 now). But the matrix of things to get beyond L4 really is,
| in the grand scheme of things, about moving beyond
| development and into delegation, or at least ownership. It's
| not management, but it is about leadership/cross-team
| collaboration and "demonstrating impact" to others. So, like
| I said elsewhere, small-p political.
|
| At least that's my experience from seeing the L4 to L5
| transition. But it may also be a product of my smaller
| office, where the number of projects is smaller, team size is
| smaller, and larger technical contributions of impact are
| harder to find.
|
| EDIT: Also I've seen a lot of change in the 9 years, in terms
| of how the organization as a whole behaves, and it is
| becoming more and more like a traditional BigCorp. I just
| checked percent/ and within engineering 86.43473% full-time
| employees are newer than me. And a lot more if you count non-
| engineering. It is a way larger company than I started in.
|
| EDIT2: I should underline, that the perf/promo process
| obviously works for a large, perhaps the majority, number of
| people. But it doesn't for all. It requires adapting to an
| organizational model that not everybody accords with. And I
| think that's in the spirit of the original topic:
| organizational structures / procedures that become your
| career goals may not make you happy, so find a company whose
| process matches what you want to get out of life. Or try.
| ralphc wrote:
| I was 33 years in the industry, as a developer. Some times I
| considered going into management, and was asked about it, but
| fairly early on I realized I would hate it and it would hate
| me.
| sli wrote:
| I'm about where you are, but when I read the word of veterans
| like this it just galvanizes my desire to leave the tech
| industry.
| dave_sid wrote:
| I'm with you
| cmrdporcupine wrote:
| Don't get me wrong, me too. I just want to retire and write
| code for fun.
| davidhyde wrote:
| > " When you know something it is almost impossible to imagine
| what it is like not to know that thing. This is the curse of
| knowledge, and it is the root of countless misunderstandings and
| inefficiencies."
|
| A few months ago I came across an interesting actively developed
| project in embedded rust which was very technical. Full of
| acronyms and concepts that I was not familiar with. It took quite
| some time to get up to speed with how it all worked and so I took
| the time to add / expand README.md files for each example,
| explaining what the acronyms meant and the general gist of each
| example. It was a worthwhile exercise for myself and I figured
| that it was worth sharing the perspective of a beginner too. My
| benign pull request remains ignored and unmerged and it makes me
| feel like a bit of an imposter. I thought nothing of it at the
| time but now I wonder if this is classic case of "the curse of
| knowledge". Perhaps the author just can't see the value of it.
| noisy_boy wrote:
| I think they are doing themselves a disservice by ignoring
| something that elevates overall understanding, ease of
| onboarding/troubleshooting and generally, the polish, of the
| project. I love documentation and usually manage to set aside
| time to add details in the README/wiki etc. It is a great way
| to share details with others and myself, six months down the
| line, because I don't have a super sharp memory.
| davidhyde wrote:
| This is true but the "curse of knowledge" from the article
| explains why this can happen. It is easy for outsiders like
| you and me to see the value of such things but as an insider
| you can become blinded by your knowledge.
| noisy_boy wrote:
| That is possible. Though I equally like documenting things
| where I can be considered an "insider" that I know only
| other "insiders" will see. I think that it is about being
| able to see the usefulness, and beauty, of a well made
| documentation irrespective of the level of
| familiarity/proximity. Either you see value in it or you
| don't.
| metanonsense wrote:
| When new collegues are joining our team or people start working
| on a subsystem unfamiliar to them, I usually tell them that
| this is a great opportunity for us as an organization and that
| they should be very vocal about everything that appears
| strange. Their lack of knowledge is a valuable asset that must
| be exploited as long as it's fresh. Unfortunately, often it
| fades within a few days when their mental mode adapts to our
| quirks.
| ncmncm wrote:
| Before you put a lot of work into something, it is a good idea
| to check if it is welcome. Nothing sucks up enthusiasm quite
| like blank rejection.
| 8iu9dua02 wrote:
| You did nothing wrong. My team produces roughly equal amounts
| of documentation and finished product code or other artifacts
| for bank consulting engagements. Knowledge within the
| customer's organization is usually scattered all over the place
| and very few people know how it all fits together due to
| employee turnover and attrition. The actual customer (VP) is
| grateful when we are able to piece together what is really
| happening and the high level state of the system while we
| streamline their systems.
| huhtenberg wrote:
| https://outline.com/6GdLnT
| GrinningFool wrote:
| I'm not sure the benefit? Reader mode makes it readable, and it
| seems like outline.com does some weirdness where it traps
| history back-navigation.
| huhtenberg wrote:
| The original link wasn't working.
| berkserbet wrote:
| Great insights for someone who is 3 year in, like myself. Key
| point for me 'Beware of Lock-In'. Been feeling that lately.
| animex wrote:
| Point 0) Always put your blog on scalable infrastructure in-case
| you get /slashdotted or Hugger Newsed to death. ^_^
| bcheung wrote:
| This is really good advice. Myself personally, I have been
| programming for decades as well and struggle with the curse of
| knowledge.
|
| Curious what other people do and what struggles they have had.
|
| Having spent time studying Category Theory I see a lot of value
| to using it in my code but it is not common knowledge and often
| confuses others when you start throwing around terms like
| functor, monoid, monad, etc.
|
| At the same time I don't want to write code that isn't as
| reusable or to that isn't as maintainable.
|
| Are we as an industry limiting our own potential by deliberately
| not using knowledge when it is beneficial for the sake of greater
| communication?
|
| My personal philosophy when working with teams is to exclude some
| of that stuff but slowly introduce it and train junior developers
| on some of the concepts in the hope that I can push that
| knowledge forward.
|
| Curious what others think of this dilemma and how they address
| it.
| jbaudanza wrote:
| I also struggle with this issue, but I've never heard the term
| "the curse of knowledge." I'm happy I have a name for it now.
| When you try to explain to people that it's difficult to
| understand that other people don't know something that you
| know, you sound a little crazy.
| dmch-1 wrote:
| that engineers don't get laid.
| dmch-1 wrote:
| It's a joke man, why downvoting? :)
| lrossi wrote:
| Something that I find interesting is that career advice coming
| from professionals having many years of experience focuses almost
| exclusively on the people aspects and not the technology:
| communication, trust, teamwork, documentation, clarity. The
| advice is clear, precise and honest.
|
| This is the opposite of what you get from new hires/juniors: they
| tend to focus on which stacks matter, what to learn, how to
| develop, deploy and maintain. Not much real advice on the
| behavioral side, to the point that people often take trainings
| for behavioral interviews and memorize "leadership principles"
| and other nonsense.
| philk10 wrote:
| "No matter how it looks at first, it's always a people
| problem." - Jerry Weinberg
| mistrial9 wrote:
| professional interview sign seen at the "interview desk" for
| work placement at an expensive school for digital creatives:
| "sit up straight; look the interviewer in the eye; wear
| presentable clothing; answer the questions asked of you" .. I
| believe the sign was there because that was not occuring in
| many cases !
| motogpjimbo wrote:
| My experience from being on both sides of the desk has been
| that devteams are relatively tolerant of candidates
| exhibiting personality quirks during the interview process -
| it's the candidate's skills that are in demand, not their
| winning personality.
|
| Maybe it's different when you interview at a FAANG company
| though? I imagine FAANG recruitment is a merciless sausage
| machine.
| folkhack wrote:
| > My experience from being on both sides of the desk has
| been that devteams are relatively tolerant of candidates
| exhibiting personality quirks during the interview process
| - it's the candidate's skills that are in demand, not their
| winning personality.
|
| I'm growing further and further away from this mentality in
| hiring because the sad truth is most of those folks who
| come in with "quirks" lack maturity. To me, quirks are
| "yellow flags" in the interview stage because it means that
| you're not able to put your own weirdness aside to fit
| socially when you arguably need to the most. Invariably
| these same "quirks" come up down the road in the employment
| with output problems, copping attitude with superiors,
| weirdness in internal/external meetings, and just general
| antisocial behavior.
|
| I get that we're all in hella demand right now but I'm
| starting to go back on my, "I'm just hiring for the
| engineering skill/talent" as an excuse to overlook yellow
| flags.
|
| The other thing is contextually, what are the quirks? If
| the "quirk" is someone being super shy/timid it doesn't
| even register on my radar as a problem unless it's
| extreme... I'm talking about the stereotypical "oh so cute
| dev quirks" like: not dressing appropriately for an
| interview, interrupting me/talking over me, talking down to
| me, comparing their last junior position to being Steve
| Jobs, being sing-songy, inappropriate jokes in _any_ way
| /shape/form, getting in arguments with themselves... etc
| etc.
|
| I'm at a point that if you can't act 95% professional in
| your first interview you're done as you're not capable of
| being "on".
| manfredo wrote:
| What sort of "quirks" are we talking about?
|
| > interrupting me/talking over me, talking down to me,
| comparing their last junior position to being Steve Jobs,
| being sing-songy, inappropriate jokes in any
| way/shape/form, getting in arguments with themselves...
| etc etc.
|
| Besides being "sing-songy", none of these things are
| quirks, they're ineffective communication or
| untruthfulness of their past positions.
|
| As far as dress and "sing-songy" go, I would agree with
| the above poster: software development tends to be much
| more inclusive of these sorts of characteristics. Jeans
| and a T-shirt is perfectly acceptable attire for an
| interview. Do your software devs wear suits 5 days a
| week? Why expect a candidate to do so, either? A
| candidate I interviewed going, "uh-oh sphaghetti-oh!"
| when they hit a segfault when running their interviewing
| solution was kind of ridiculous, but ultimately has no
| impact on their contributions as a developer. Factoring
| in these kinds of thins into the hiring decisions is
| ultimately about including people from a culture similar
| to your own. Different cultures have different
| definitions of "weirdness" so selecting based on the
| ability of the candidate to identify what is "weirdness"
| is ultimately a cultural litmus test. And expecting male
| candidates to be shaved, as per your other comment, is
| just blatant cultural discrimination - some demographics
| like Sikhs could even sue you for illegal discrimination
| over this. This cuts both ways, both the case where a
| candidate in a T-shirt and jeans gets rejected for not
| wearing a suit and when a suited up candidate gets
| rejected for being too formal. Both ultimately hurt the
| company by excluding effective workers.
| rusk wrote:
| > Invariably these same "quirks" come up down the road in
| the employment with output problems, copping attitude
| with superiors, weirdness in internal/external meetings,
| and just general antisocial behavior.
|
| Yep, I've been that guy! Had huge problems for a while.
| Mercifully my team/department/business put up with me for
| the most part, but I did have to suffer for a while.
| Learnt some invaluable lessons though and I'm quite happy
| to be a fitter happier and more productive individual!
| (Yes Radiohead reference but really not as bad as it
| seems:)
| nicoburns wrote:
| > not dressing appropriately for an interview
|
| What is "dressing appropriately". I wore a suit to my
| very first interview for a dev position and very nearly
| didn't get the job because they were worried I wouldn't
| fit in (luckily I was able to explain that I don't
| usually wear a suit). The other ones in your list, sure.
| But I don't think those are what people typically means
| when they talk about quirks.
| Mauricebranagh wrote:
| :-) I went to an interview (London UK) for a big name
| agency suited and booted and was interviewed by some one
| in a scruffy t shirt that looked like his dog had been
| sick on it.
|
| I sort of twigged that I was over dressed when on the way
| to the interview some one stopped me in the street and
| asked me the way to the "Ivy"
| folkhack wrote:
| > I wore a suit to my very first interview for a dev
| position and very nearly didn't get the job because they
| were worried I wouldn't fit in
|
| Yeah - I hate this. I had people at my last position give
| candidates negative points because they wore a suit and I
| went $%&#ing ape. In positions that I've held in the past
| it's been the appropriate action to wear a suit due to
| heavily corporate environments, and I see it as 110%
| normal that someone puts on a nice suit for an interview.
| The action of wearing a suit (or tie for that matter) to
| an interview _should never_ be seen as a "cultural fit"
| problem - _I 'm looking at you SV..._
|
| Sorry that almost happened to you. That's some bullshit.
|
| ---
|
| Overall a nice well-fitting button down + a pair of well-
| fitting dress slacks is what I would recommend.
| Personally, I wear a slim fit _brand new_ white button-
| down (ironed), nice dark blue chinos (ironed, not
| pleated), and not-scuffed brown wing-tips. Often I also
| wear a tie, but am considering not thanks to a derelict
| SF "big-wig" grilling me in an interview as to "why are
| you wearing a tie?" All I wanted to say is "does it
| matter?" _(offender: you 're reading this don't do that
| again.)_
|
| Also get a solid hair cut, ensure you're shaved if male,
| and yeah - sit up and be confident while you're in the
| chair. Body language _does_ matter, and your interviewer
| will subconsciously notice regardless if they 're giving
| you a "pass" or not.
| nicoburns wrote:
| > The action of wearing a suit (or tie for that matter)
| to an interview should never be seen as a "cultural fit"
| problem
|
| I would agree and would go as far to say that dress in
| general should never be a hiring criteria for a non-
| customer facing position. Unless there are hygiene issues
| or they are wearing something actively offensive.
| folkhack wrote:
| I'm slightly more conservative - I've had people show up
| in t-shirt and jeans and have turned them away because I
| feel like they're breaking the social contract of what an
| interview is. Like - totally clean/non-offensive t-shirt
| and jeans.
|
| In a lot of my engineering roles I have had to be
| internal/external facing and do things like budget
| presentations, work with partners, etc. Before that, I
| was a general web/app dev and we would get pulled along
| to client meetings all the time to collect spec, ensure
| that it was a good sales fit, etc. I'm not saying I had
| to be fully decked-out but being able to throw on a
| button down and tuck it in means that you "fit-in" to
| these situations.
|
| For me, if someone is showing up in a t-shirt and jeans
| it's a red flag that you can't be bothered to dress semi-
| professionally which has been an occasional (but hard)
| requirement of me since day-1 of my career. 100% this all
| is anecdotal, and specific to my own needs/experiences.
| bbbobbb wrote:
| I think this is fair to both sides. I dress casually for
| interviews not only because that is what I prefer to wear
| but also in hopes of getting rejected by anybody who
| would consider that a red flag.
| folkhack wrote:
| Yep. And that's better for both parties involved. Just
| don't be offended when I turn you away at the door to not
| waste either of our time.
| samatman wrote:
| This is in fact the advantage of having a widely-
| understood dress code for things such as interviews: that
| way no one has to play guessing games, you just show up
| as expected and it's one less thing to think about.
|
| Unfortunately, our industry has no such thing, so I
| always ask before an interview. So far the answer is
| always "uh, we just wear normal clothes", "casual is
| fine" or once "just wear clothes, please, this isn't
| _quite_ Burning Man " (ended up working at the last
| place), but: this was in the Bay Area, so YMMV.
| bcrosby95 wrote:
| I would expect it to depend upon the company.
|
| Dress code doesn't really factor for me, but I've worked
| for the same place for a while now and we've always been
| 95% remote. Half of us just wear whatever we slept in the
| night before. Most people don't get dressed until lunch
| time. Even in the office it doesn't get much fancier than
| a t-shirt and jeans. I guess our tech lead wears a button
| down shirt, but his jeans usually have giant holes in
| them, so I would call that a wash.
|
| Expecting an interview candidate to wear something nice
| would feel a bit hypocritical.
| izacus wrote:
| Believe it or not, checking if the candidate is able to
| dress professionally and appropriately for the occasion
| is one of the major things being tested on most white
| collar job interviews.
| kemiller2002 wrote:
| I would agree although sometimes this is a little too much.
| I have seen instances where they solely focus on the skills
| and end up hiring jerk. Ultimately, that causes way more
| trouble than a weak skillset.
|
| An interesting experience I had at a previous company was
| that they really put culture almost above all else. It
| sounds great, but in all honesty it was actually depressing
| and horrible after a while. It almost always came down to,
| "Well we don't want to hire X person, because it's not a
| good culture fit." The real issue was that they wanted to
| hire people they could hang out with / mold into their way
| of thinking. No new ideas, and everything pretty much
| stagnated. If that's what you were looking for, then it was
| great, but people who think like that aren't typically the
| ones that can hit the homerun when you need to.
| zx14 wrote:
| Most juniors have a much narrower focus in their day to day
| activities. Their responsibilities tend to be far more focused
| on churning code and dealing with cool or bad tech choices,
| whereas the more senior you get, the wider or high level your
| job can become.
| stroz wrote:
| I couldn't agree more, that said, I believe the difficulty for
| new hires in software engineering typically comes from the
| relentless focus on coding interviews.
| 74d-fe6-2c6 wrote:
| I think it is because the older you get you realize that all
| those projects are anyway just notches on some stick. For
| example everybody with some experience will choose a boring
| project with aweseom colleagues over a cutting edge project
| with a bunch of self-obsessed nerds. Life is short.
| mcguire wrote:
| Speaking as a career-long technical person,
|
| 1) All of those people aspects are _very, very_ important.
|
| 2) Stacks don't matter. Languages don't matter.
| Editors/IDEs/whatever-the-hell-else doesn't matter. What I used
| to call a "firm theoretical grounding" does matter.
|
| What does that mean? At the base, the ability to write clear
| code that other people can read, and the ability to read code
| that other people have written. (Don't laugh, it's not uncommon
| to get called in when someone has bugs (or features) they can't
| get fixed after they've painted themselves into a corner.) (For
| me, the key to this is formal logic and what is variously known
| as axiomatic semantics (http://homepage.divms.uiowa.edu/~slonne
| gr/plf/Book/Chapter11...) or Hoare logic, or predicate
| transformer semantics. Theoretical, right? But the ability to
| think about a piece of code as a block of text, without
| "simulating the computer" is darn useful.)
|
| Further, algorithms and data structures. No, you don't have to
| memorize a bunch of algorithms. But it's a good idea to
| understand what kind of things are out there and what they can
| do, as well as having experience writing them yourself. (I get
| downvoted a lot, but I do have to point out that everytime
| anyone puts code in an editor, they're building a data
| structure or writing an algorithm.)
|
| Then, at least some knowledge of computer architecture and all
| the stupid little electricy bits. :-)
|
| Then there is a stack of things that build on that, some of
| which are only relevant to some tasks: databases, network
| protocols, and so on.
|
| None of this has changed fundamentally in 30 years. The only
| major change I've seen is an increase in the importance of
| continuous math---which I noticed because I've always had a
| hate-hate relationship with trig and calculus and so on. But
| all of machine learning and statistical techniques are based on
| that nastyness, so you can't ignore it any more.
|
| Why does nobody mention technical things? For one thing,
| they're hard. You can practice communication at the grocery
| store. Not so much with technical matters. Further, the people
| aspects are important everywhere, whereas technical things just
| aren't. And at some point, it's easier to convince some one
| else to do the work while you have the ideas. (Personal motto:
| Ideas are cheap. Implementation matters.)
|
| Finally, technical mastery is not really encouraged. Outside of
| academia, there are no real incentives for it. (Inside
| academia, there are almost no incentives for it.) After 20, 30,
| or 40 years, people will migrate on to something else, even if
| they don't like it or are really horrible at it.
| JMTQp8lwXL wrote:
| Both, to some degree, matter. If your team makes poor technical
| decisions, that could spill over to eroding team trust. Your
| success is generally tied to how your team performs in
| aggregate. If your peers mess up, that could impact you
| professionally as your team's overall standing within your
| organization declines.
| marcinzm wrote:
| >Not much real advice on the behavioral side, to the point that
| people often take trainings for behavioral interviews and
| memorize "leadership principles" and other nonsense.
|
| This is what FAANG interview generally look for so why is it a
| surprise that potential hires focus on it? Amazon literally
| says that you need to highlight all the leadership principles
| in the stories you tell when answering behavioral questions.
| Granted, FAANG barely asks behavioral questions for senior
| engineers (and then it's like 90% project and bureaucracy
| management) much less junior engineers.
| lrossi wrote:
| Do you know why Amazon is focusing so much on the Leadership
| Principles questions, yet there seem to be so many horror
| stories from people who work there? I am genuinely curious
| why they don't manage to filter out the jerks.
| marcinzm wrote:
| As I see it, the Amazon leadership principles are designed
| to select for jerks. Specifically jerks who make money.
| Just look at them. One or two out of fourteen indicate to
| not be a jerk (Earn Trust, maybe Hire and Develop the Best)
| while multiple other ones rewards you for being a jerk if
| you succeed (Disagree and Commit, Bias for Action, Insist
| on the Highest Standards, Are Right A Lot, Ownership,
| Deliver Results, etc.).
|
| edit: Amazon's goal isn't to be a nice place to work, it's
| to make a lot of money and everything else is secondary to
| that. They are so far succeeding splendidly at that goal
| across multiple verticals so arguably their approach works.
| I wouldn't want to work there myself but you can't argue
| with results.
| disgruntledphd2 wrote:
| I think that you may be onto something there. I have
| noted that when I meet (many) ex-Amazon employees, a lot
| of them (especially on the business side) are not nice
| people to work with (backstabbing, destructive political
| games etc).
|
| It's come to a point where I kinda assume that they are
| likely to screw me/other people if I don't know
| otherwise.
|
| (Obviously this is a generalisation, I'm sure there are
| loads of really nice people at Amazon).
| milesvp wrote:
| I recently looked at some of their hiring material, and one
| of the before after leadership showed a lot of bullshit in
| the after. The content was nearly the same, but it felt
| embellished in a way that left me feeling hollow. It was
| some oncall event, of which I've experienced dozens, and
| the second version just felt oddly misguided for the sake
| of saying the magic words the interviewer wanted to hear.
| The leadership principles seems to be reinforcing bullshit.
| We'll tell you what we want to hear, and you'll tell us
| what we want to hear. Do our principles line up? 'Who
| cares? You told us what we wanted to hear.' It's
| effectively a jerk pass filter at that point.
|
| Mind you, there's some of this in all interviewing, but
| from some people I've talked to, Amazon seems to really
| love these leadership stories.
| xyzelement wrote:
| What you're saying is important for everyone to internalize.
| I'll spin it like this:
|
| Your job satisfaction/pay are a function of your impact. Your
| impact is a function of your leverage.
|
| If you're a "pure coder" who doesn't have any of the other
| skills you mentioned, your output is incredibly limited. At
| best, you produce a day's worth of code in a day, but you also
| require someone to manage you closely to make sure you code the
| right stuff.
|
| The more of these other skills you have, the more you can (a)
| work independently (b) make others more productive and (c) make
| sure your team/business is doing the right things and (d) drive
| overall efficiency.
|
| The more of these things you do, you become orders of magnitude
| more impactful than a pure coder.
| KineticLensman wrote:
| Agree.
|
| One of the most important skills is the one he describes like
| this:
|
| >> The more specialized your work, the greater the risk that
| you will communicate in ways that are incomprehensible to the
| uninitiated.
|
| In my experience (35 years), this isn't just about knowing
| the right way to describe things, it's also understanding
| what things to concentrate on when communicating, and what to
| ignore. If you are a tech person communicating with a
| decision maker, they are typically looking to understand
| options and their implications and risks, not the details of
| how the options work. They can then decide, based on their
| (presumably) better knowledge of the wider context, which
| options to select. If the decision makers are genuinely
| intelligent and motivated, but their eyes glaze over when you
| describe something, chances are you have chosen the wrong
| things to communicate to them.
| xyzelement wrote:
| Yup. I agree with you (and your pragmatic approach to
| helping the raptors!)
| KineticLensman wrote:
| Thank you! (Actually the raptor conservancy [0] is
| interesting from this perspective as well. I'm a newbie /
| junior in that context, but I can see standard employee
| patterns that I recognise from the tech industry, e.g. in
| terms of people who know to report and / or delegate
| well, or to make effective decisions vs. be indecisive.
| Perhaps I'll have to see if I can document _my_
| observations on what I 've learned in my career).
|
| [o] https://news.ycombinator.com/item?id=25650535
| that_guy_iain wrote:
| > If you're a "pure coder" who doesn't have any of the other
| skills you mentioned, your output is incredibly limited. At
| best, you produce a day's worth of code in a day, but you
| also require someone to manage you closely to make sure you
| code the right stuff.
|
| This seems to miss the point of teams. Everyone should have a
| role if you hire someone as a software engineer and they
| spend all their time doing devops because they like it more
| you've made a bad hire. If all your engineers are having
| product meetings with various departments then you've again
| made bad hires. Everyone should have their role and fullfill
| that role to work as a successful team. People thinking
| they're above fullfilling the role they were hired for is one
| of the fast ways to have a poor performant team. To put this
| into sports you don't want your defender to be constantly
| hanging around the other team's goal mouth.
| one2know wrote:
| Found the manager. This is just more developer hate drivel.
| Yes, if you think managers are more valuable, then obviously
| you are going to say engineering work is "incredibly limited"
| and manager activities are "orders of magnitude more
| impactful" Listen, no amount of ass kissing and brown nosing
| is going to solve actual tech problems.
| macintux wrote:
| This tone is unwelcome on HN, which is probably why your
| previous comments have often been downvoted and flagged.
| one2know wrote:
| Bashing and shit talking software engineering profession
| is welcome on HN?
| macintux wrote:
| Let me paraphrase the original comment to make my next
| question easier to answer:
|
| Effective software engineering in a business context
| requires awareness of business needs.
|
| Which part of that is "bashing and shit talking"?
| [deleted]
| usefulcat wrote:
| It sounds like you're making assumptions in bad faith. I'm
| a SWE (i.e., not a manager) and I didn't read the comment
| at all like you did. On the contrary, I quite agree with
| it.
| one2know wrote:
| Well, as someone who has saved my company's ass multiple
| times to the tune of millions of dollars I think
| technical solutions are orders of magnitude more
| impactful and foofoo talk bullshit is incredibly limited.
| So I guess we will have to agree to disagree. Maybe noob
| coders "produce a day's worth of code" and that's all
| they can do, that's your perspective.
|
| I've sat through dumb two hour meetings about deciding
| which words in a document should be capitalized. Is that
| what is meant by "make sure your team/business is doing
| the right things?"
| steve_adams_86 wrote:
| I think what you're missing here is that the original
| comment isn't suggesting code doesn't solve problems when
| it counts. The thing is, developers often code things
| they never needed to. Or they code things off spec. Or
| they code things outside of the convention of what's
| appropriate for their immediate team or long-term needs
| of the product. The list goes on. Output could seem good
| for a long time before it becomes problematic, then the
| pure coder simply codes more to solve those problems.
| This is very circular and makes up a lot of work done by
| software developers in my experience.
|
| I agree with what you're saying in part. Pure coding
| skills are essential, especially in critical situations
| like that. Soft skills won't fix broken things, for
| example. Salespeople can't deliver the features they
| promise without someone to develop them.
|
| However, soft skills can help someone with excellent
| coding skills to know what to apply their skills to and
| when, and how to integrate their skills within a broad
| team of different disciplines.
|
| This is arguably true in any field; I think it's often
| missed in software development because people have such a
| difficult time distinguishing boundaries of things. The
| problems you're solving, when you're passively or
| actively solving problems, when output is applicable to a
| specific problem, etc. Even software engineers themselves
| struggle with this.
|
| Your ability to save your company's ass is an excellent
| skill to have, but it isn't directly related or exclusive
| to what the original comment was saying.
| one2know wrote:
| You have a very noob view of software engineering. You
| make a lot of generalizations about coders to support the
| theory that coding is low impact because coders fuck up a
| lot. Noob coders fuck up a lot.
|
| When I saved my company's ass those times, no non-
| technical people were present and it was wholly technical
| knowledge that solved it. I could have and probably
| should have ignored the problems and let the talkers try
| to fix it and take the blame for millions in losses. So
| it is very apropos to the original comment.
| [deleted]
| closeparen wrote:
| This is the party line. It misses that "a day's worth of
| code" is highly unequal across individuals. The people whose
| "day's worth of code" are most valuable, quickly get pulled
| off of spending their days that way.
|
| It appears that they key skill is coordinating a lot of
| developers, because the ones left developing are the ones you
| need a lot of (and who need close supervision) to get
| anything done. Managers will never rock this boat, because
| their career KPI is the number of people they manage.
| draw_down wrote:
| It's ok to just produce a days worth of code in a day. This
| is not a failure mode or something to be avoided. It's ok to
| just work a job. Not everyone is focused on "impact" and all
| that junk, and nor does everyone need to be.
| watwut wrote:
| If you are junior you would make mistake to ignore technical
| aspects of work (stacks, what to learn, how to develop, deploy
| and maintain) in order to focus on communication, trust,
| teamwork, documentation, clarity. While communication is
| somewhat important for juniors, but usually the technical
| aspects are even more missing. It is when you have technical
| aspects down when the other aspects start to matter more.
|
| Also, juniors are not in political situations where the other
| aspects matter all that much. Generally, they find themselves
| in simply political situations. As long as they are not
| downright toxic, it is ok.
| burade wrote:
| Hum... maybe it's because they have so much technical expertise
| that they are able to have insights into other things?
|
| Technical knowledge is still very important, and it's the basic
| foundation of being a software engineer, and maaaaannyyyyyy
| people out there don't even know the basics.
| reaperducer wrote:
| _This is the opposite of what you get from new hires /juniors:
| they tend to focus on which stacks matter, what to learn, how
| to develop, deploy and maintain. Not much real advice on the
| behavioral side, to the point that people often take trainings
| for behavioral interviews and memorize "leadership principles"
| and other nonsense._
|
| This was exactly the experience I had not so long ago.
|
| Management brought in a new "team leader" to "shake things up"
| with "new ideas."
|
| She spent most of her time reading management books, taking
| online management courses, and going to management seminars.
| She almost never spoke to the "team," and when she did, treated
| us like underlings.
|
| They gave her two years to make a difference, and then kicked
| her out in the first round of COVID cuts.
| proverbialbunny wrote:
| Wow. While I do not have experience with management courses,
| and seminars, one book I read about management
| (https://www.amazon.com/First-Break-All-Rules-
| Differently/dp/...) talks about exactly this scenario. I am
| surprised to hear about it in the wild.
| marcus_holmes wrote:
| I entered the industry with no degree, having taught myself to
| code. After approx 15 years as a developer, I decided to get a
| degree, because it was becoming a problem (Australia is very
| sensitive to qualifications). I decided to get an MBA because
| all the hard problems I'd met were people and/or business
| problems.
|
| The tech is generally easy in commercial coding. There is
| usually a definitive answer, and if not then the trade-offs are
| generally well-known. It's rare to run into a problem that
| requires complex technical knowledge, and in those cases it's
| fine to hire a consultant to help.
|
| But the people problems are hard. Getting clued-up on these is
| important.
| lrossi wrote:
| What kind of resources would you suggest to someone who wants
| to get better at handling people problems?
| tiborsaas wrote:
| You can also try therapy.
| marcus_holmes wrote:
| Totally agree with this. Knowing how to handle your own
| emotions is a key "people skill". And therapy really does
| help with this.
| [deleted]
| marcus_holmes wrote:
| First define your problems ;)
|
| If you want to get into management and deal with those
| kinds of people problems, then there are lots of management
| training courses around. An MBA is at the upper end of that
| range.
|
| If you're having problems fitting into teams and getting
| along with people (actually quite common in dev teams),
| then maybe look at therapy or personal coaching. I spent a
| few years in therapy and it really helped.
|
| If it's office politics and the like - some workplaces are
| toxic. I can't deal with those even with the training and
| experience. Life's too short to deal with that bullshit ;)
| kingnothing wrote:
| Depends on what you mean by "people problems".
|
| Perhaps read some books on negotiation if you have issues
| getting others to see your point of view.
|
| Nervous about speaking in front of a group? Try
| Toastmasters once the world opens back up, or hire a coach.
|
| Books are a good first resource once you identify the areas
| in which you want to grow.
| airstrike wrote:
| Wow. This must be the very first pro-MBA comment in the
| history of HN. Feels refreshing!
| marcus_holmes wrote:
| Being a developer with an MBA is a rare combination ;)
| Worth it, from my experience.
| Mauricebranagh wrote:
| A mature MBA done after 10-15 years experience is very
| different that some one who went from BSC direct to a MBA
| (to game immigration hurdles in a lot of cases)
| mattmcknight wrote:
| > they tend to focus on which stacks matter
|
| This is not just a junior problem. A lot of "people problems"
| seem to come from fighting over which stack to use. (and most
| people fight for whichever stack they are best at, to maximize
| their own personal contribution). I always spend a lot of time
| asking people what technology they would use to solve a
| particular problem, what technology they really don't like,
| etc. It saves a lot of trouble fighting over things if you get
| a team that is willing to go with a particular technical
| approach and is more important than most "cultural fit" issues.
| Viliam1234 wrote:
| In my experience, this mostly happens with people who only
| know one technology. Many juniors are like this. On the other
| hand, when this happens with a senior, they fight extra hard.
|
| I suppose it also depends on company culture. What happens if
| a technology you have never seen before is selected for your
| project? Are you given some time to learn and is it expected
| that your initial contributions will be smaller, or are you
| supposed to be just as fast as people who used it for last
| ten years and get negative reviews otherwise?
| lumost wrote:
| Generally speaking - your technical qualifications value over a
| replacement hit their peak sometime between 3 and 10 years into
| your career for most folks. Meaning while you may be
| particularly skilled, learning one more discipline, stack,
| technique, or language probably won't let you get a particular
| job done any better or faster than the next engineer.
|
| Many engineers move to management at this point, which requires
| that you can mentor and grow a team of engineers, set goals,
| drive projects to completion, and manage your team through
| performance reviews.
|
| Folks who stick to the technical path need to become an
| indispensable piece of technical glue across N teams, keeping
| them all building in the right direction and not crushing each
| other. This job requires deep technical knowledge but often
| doesn't involve a ton of coding e.g. Linus Torvalds.
|
| If a junior engineer showed up with the behavioral
| qualifications of Torvalds and the technical skill of a junior
| engineer - they would still be a junior engineer and unable to
| build trust, guide a team effort, or other activities.
| dboreham wrote:
| "Psychology is eating the world"
| rusk wrote:
| Well Zuckerberg's major was psych so you might be onto
| something there ...
| [deleted]
| rodolphoarruda wrote:
| 7. Dress Code It has changed a lot. From suit and tie to whatever
| you feel like wearing.
| zerop wrote:
| It was good to read this... But today most of the big/famous
| companies (except Tier 1s) aren't giving importance to these.
| Infect in one of JDs of a big company for Engineering manager
| role I saw "Ability to negotiate" as a requirement skill for that
| job. I would blame the fast-fail culture brought up recently.
| barnacled wrote:
| Some cynical lessons from 15 years in:
|
| 1. Politics is everything - how you are perceived is politics,
| whether you get assigned the projects you want is politics,
| career progression whether technical or managerial is entirely
| politics. You will be told various nonsenses about 'flat
| structures' and 'meritocracy' throughout your career but it's
| bollocks. Play the game badly and the flat structure is your
| career.
|
| 2. Most programmers don't care - as much as you might care about
| software engineering principles or even minimal levels of quality
| in your work, you will be shocked at the degree to which most of
| your colleagues do not. They might give lip service to it but
| when it comes to it most justify doing a crappy job by hand
| waving about being practical. If you talk even mildly about code
| quality expect to have it patronisingly explained to you 100
| times over that you are a perfectionist and customers don't care
| and etc. Etc. (Of course these arguments are easily rebutted
| straw men but good luck getting that across).
|
| 3. Raising what's right usually hurts you - people do not like to
| hear uncomfortable or irritating truths. See point 1. Pointing
| out that something is a risk or severely broken is more likely to
| get you hassle and lower people's view of you and God help you if
| you are proven right - there is never a 'oh you were right!'.
| Nobody likes to be made to look bad. Again see 1.
|
| 4. Never underestimate how shit the code is in your next job -
| the interview very rarely gives you the slightest insight into
| the quality of a new employer's codebase and never be surprised
| at just how terrible it can be.
|
| 5. We'll fix it later means we will never fix it - technical debt
| is a lot like national debt - ever growing and rarely paid down.
| If you are fobbed off with a 'we will refactor that later'
| comment take that to mean 'this is shit and I am fine with that'.
|
| 6. Sideways shifts reset your career to zero - there is no such
| thing as treating development experience as fungable. You are
| only as good as your years in this particular slice of the
| industry and more often than not you are only as good as your
| years in this particular company.
|
| 7. Fuck you pay me - at any time if you are told by an employer
| that you are part of a family or that your pay rise couldn't
| happen because you are already paid highly for your title or
| other such nonsense, start looking for another job, you are being
| used.
| supernova87a wrote:
| One of the tenets though, "6. Be Honest and Acknowledge When You
| Don't Fit the Role" only is fair to the person if the
| team/company also follows that advice.
|
| If a team or company does not value, or cannot tell, or does not
| act if someone is incompetent and unfit for a role, then this
| advice penalizes those who are honest, and rewards those who are
| good at faking competence.
|
| You need to have a structure of integrity within which to
| operate, in order for honest behavior to be rewarded.
| lainga wrote:
| I think it's fair. For me, the penalties and rewards you talk
| about are outweighed by some countervailing factors outside the
| realm of career development. Even if your current team isn't
| honest, the ultimate structure of integrity is your very own.
| marcinzm wrote:
| I don't see how your statement disagrees with what he said.
| He's talking about self-acknowledgement which has nothing
| directly to do with the organization. For example, if the
| organization values fake competence and you don't then you need
| to self-acknowledge that and either start faking it, change the
| organization or find a new job.
| kazinator wrote:
| It's clear doesn't say "acknowledge it loudly to everyone
| around you so you get kicked out of the role". He says there is
| more than one solution (e.g. grow to fit the role), and that
| it's about having the self-knowledge not to stay in a bad
| place.
|
| If an organization pervasively rewards competence fakers, where
| will that whole organization be in ten years anyway?
| gwbas1c wrote:
| I suspect that "or the role can evolve" implies that some roles
| come with unrealistic expectations.
|
| I see this when I see job postings with a long laundry list of
| qualifications and responsibilities. I suspect that part of
| succeeding in such roles is figuring out how to evolve the role
| to be more reasonable.
| tannhaeuser wrote:
| What I'd be really interested in is how tech churn is perceived
| by people older than me. I'm only 30 years in, so I tend to
| defend my generation's choices such as POSIX, SQL, XML, SOA,
| Java, and C/C++ before that (plus special-purpose pet peeves of
| mine such as markup/SGML and logic programming which came before)
| though I'm also claiming to be proficient in and generally open
| towards new tech. I consider most of supposedly new tech as
| rehashes of things past rather than real progress, and to be just
| lock-in schemes and sucking in another way compared to the tech
| that it is supposed to replace. But I'm really uncertain if I'm
| just falling victim to generational effects, like, say, the
| proverbial COBOL programmer being ridiculed by younger devs to
| instinctively grow their own tech career. Still, for me, there's
| a moment around 2006-2012 when the industry went all-in on "the
| Cloud" and consumerisation of IT, when before I saw canon,
| progress, and consensus through standardization.
|
| I guess this is something that can't be objectively measured; but
| I can say that initiatives for standardization have almost
| dropped to zero compared to the 1990s and 2000s.
| gen220 wrote:
| > initiatives for standardization have almost dropped to zero
| compared to the 1990s and 2000s
|
| I think OSS adoption explains this. Standards were all about
| advocating for common interfaces, even if the implementations
| were proprietary. Proprietary software was more a thing in the
| 90s and 00s.
|
| Nowadays, common practice is to use open _implementations_ ,
| not just open interfaces. Nowadays, we only see widespread
| initiatives for standardization when people are trying to
| cement the long-term survival of their implementation's
| interface.
|
| See, for example, the Open Container Initiative, put forward by
| Docker (a company that engineers were concerned about betting
| the barn on, in 2015).
|
| Contrast that with S3, which does _not_ have a corresponding
| commitment to an open interface standard. Their interface has
| been copied nonetheless by several vendors (DO, Linode), making
| it a de facto standard, albeit a fragile and autocratic one.
|
| Basically, I'm not sure if standardization has evaporated, I
| think it's diffused, and OSS is (ironically?) a contributing
| factor.
| waldrews wrote:
| Curious how logic programming fits in with the rest of that
| list?
| tannhaeuser wrote:
| Why wouldn't it? I've always been a fan of polyglot
| programming and use of languages oriented towards specific
| use cases, as opposed to language-centric ecosystems. Now
| Java doesn't exactly fit that criterion ;( but makes up for
| it by being portable, relatively open, and cross-platform,
| and being instrumental in having prevented Windows dominance
| on the server-side in the 1990s. And it pays the bills.
| Haven't used it for new personal projects since 2008 or so,
| though.
| scsilver wrote:
| As a young blood, 5 years in, got hired by learning react in
| the great JS hiring of the mid 2010s, I look back towards those
| standards bodies as something that would be very beneficial
| now. All we have is chrome creating standards by monopoly.
|
| Maybe I have a older mindset aswell. My training in in Civil
| Engineering and I have my expectations for standards bodies set
| pretty high because of it.
|
| The code is so high level now, going through algo and data
| structures I see the benefit of that fundamental knowledge, but
| also see that you can be a very valuable engineer to a company
| without it(thanks to the rich developer ecosystem for that)
|
| If we think about the maturity of software like a biological
| ecosystem, maybe the zen garden built by past engineers has
| overgrown into a dense and varietal forrest. Im not sure if its
| bad or good, maybe there are more niches to move into.
| breck wrote:
| I'm only 15 years in but have thought about this a lot. I agree
| with you that there is nothing new under the sun; that we just
| cycle back through old ideas; fashions come and go and come
| back.
|
| However, the environment changes so often old ideas go from
| being "possible" to "they just work" or "possible but really
| slow" to "instant".
|
| These environmental changes can make orders of magnitude
| differences, and cause old ideas to suddenly feel very
| different in practice.
|
| When I think of programming languages for example, of the
| languages you mention, a lot of their design (like matched
| brackets in XML), were decisions that made a lot of sense when
| we had monochrome editors, but now with extremely fast and
| advanced IDEs, we can take old PL ideas from the 50's and
| design languages with IDEs in mind that are a lot less cryptic
| and concise.
| tannhaeuser wrote:
| Good points. Though if you've picked up computing from almost
| the ground up (soldering, hardware hacking, low-level
| programming, of which I did only a little however), there's
| that experience when sitting in front of an overwhelming,
| notebook-melting IDE where you say to yourself "I don't need
| all those arbitrary abstractions; I've got a pretty good
| understanding of what I want to achieve, thank you very much"
| and realize the cognitive overhead can become a net-negative
| compared to the perceived problems that modern IDEs are
| attempting to solve. Matter of taste, of course.
|
| As to XML, matched end-element tags (if that's what you mean)
| actually were a simplification compared to SGML from which
| XML was derived/subset. In SGML, you can omit/infer end-
| element tags or can type "</>" to make SGML auto-close the
| most recent element. I agree the verbose-ness of XML looks
| especially redundant since it's always the most recent
| element you have to close anyway whereas SGML (in principle,
| at least) has overlapping ("concurrent") markup. And I can
| assure you that around 1998 we had 32bit color monitors and
| IDEs didn't look all that different from today ;)
|
| But back to the topic, I believe a lot of material has simply
| vanished from the 'net, or isn't accessible through search
| engines anymore.
| twh270 wrote:
| I'm 30 years into this industry also. We all have a tendency to
| defend and use what we're comfortable with, which often is what
| we learned ages ago. I try to challenge myself regularly by
| looking for my biases and assumptions. (Easier said than done,
| of course.)
|
| However, I'd say the rate of "tech churn" has become impossible
| to keep up with in the most popular stacks (Java[Spring], .NET,
| front-end, Node). If you are in other areas, things tend to
| move slower.
|
| I think the initiatives for standardization move at about the
| same rate as they used to, but the increasing amount of
| industry churn makes it seem like standardization has slowed
| down.
| Ericson2314 wrote:
| Most of this is perfectly archetypical "hindsight says it's all
| about the little things", exactly what we expect our elders to
| say.
|
| But consider no 100 year old dying in 1950 would bother impart:
|
| > At the end of the day, sweaping the barn really is how all my
| children made it to age 5
|
| > A rust-free butterchurn keeps those fingers attached, don't
| rest though there's a wall of glass
|
| Good Timeless advice is a function of stagnation.
|
| > Fighting complexity is a never-ending cause.
|
| > Beware of Lock-In
|
| These ones, though, I like. We should strive to understand
| problems in full generality, which may increase simplicity. But
| our current cloud-and-Docker-snakeoil trend is either epicycles,
| not ellipses, or lock-in, never neither.
| simon_mannes wrote:
| > Teams move at the speed of trust.
|
| I'm only 7 years into my professional software engineering career
| and this really stuck with me. Over the last two years I had the
| honor to work with an awesome team on an interesting project, and
| yes, trust is the basis of exceptional teamwork.
| coffee wrote:
| > At EDS, the culture wasn't like this. People moved in and out
| of management roles. There was no stigma associated with moving
| from roles with greater scope, like strategic planner, to roles
| with more narrow scope, like PM or project-level developer.
|
| This sounds amazing. I'm curious...how does salary change? Or
| does it change? How is all of this handled...
| SPBS wrote:
| > Computer Assisted Software Engineering (CASE) tools, COTS,
| Enterprise Resource Planning products like Peoplesoft and SAP
| and, yes, even Ruby. They claim amazing reductions in cost and
| time if you buy into their holistic development philosophy. What
| is not always as obvious is the significant up-front costs or the
| constraints you may be committing yourself to. Lock-in used to
| primarily happen with vendors, but now it can happen with
| frameworks too.
|
| Is the author calling Rails as 'lock-in'?
| [deleted]
| steve_adams_86 wrote:
| I saw a reference to Ruby, but not Rails. Are you inferring
| Rails from the mention of Frameworks towards the end?
| swyx wrote:
| yes, but lock-in can be worth it, and Rails is increasingly
| worth it as the ecosystem and core grows. i wish we had an
| alternative term to "lock-in" that had more neutral instead of
| negative connotation. it's got tradeoffs, like with anything,
| but doesnt mean we gotta be scared of it.
| eloff wrote:
| It is no? It's not easy to rewrite into something else if you
| need to. With rails the biggest reason you might need to do
| that is the abysmal performance. You need twenty servers to do
| the work you could have done with one.
| __jem wrote:
| Is it not? Even if it's open source, I would view monolith
| frameworks as a form of ecosystem lock-in. We use Spring at
| work and I would certainly describe us as suffering from "lock-
| in" to the Spring ecosystem.
| mewpmewp2 wrote:
| In which case are you not going to lock in building something
| like that?
|
| Even if you opt to go framework-less you are now locked in to
| whatever you are building.
| gshulegaard wrote:
| Not quite the same. I moved away from Django some years ago
| when I ran into a bug that I traced back to the Django ORM.
| At the time it was neither obvious to fix nor easy to
| replace the Django ORM with something like SQL Alchemy.
|
| It's not necessarily about avoiding rewriting entirely, but
| rather minimizing the amount of rewrite required if you
| have to improve, change, or fix something. If your
| roadblock is in the framework, the bigger the framework,
| the more you have to rewrite.
| codingdave wrote:
| This is somewhat true, but that is why separation of
| concerns is a best practice. Maybe you do have one piece of
| the stack "locked in" to Rails, but the rest of the stack
| can stay in place if you want to move from Rails to a
| different framework.
| nahname wrote:
| It's hard not to become jaded when every framework turns out to
| be just another team's personal preferences. I would say the
| statement is generally true about frameworks, but not true
| about rails. Perhaps the author did not spend enough time with
| rails.
| BossingAround wrote:
| > It's hard not to become jaded when every framework turns
| out to be just another team's personal preferences.
|
| Isn't that a definition of a framework? A more or less
| opinionated way to structure a particular type of an
| application?
| citrea wrote:
| "What I've learned in 45 Years in the Software Industry" - a 1000
| Word article. (:D)
| qwantim1 wrote:
| Great advice!
|
| A correction:
|
| Ruby the language is not really a lock-in problem.
|
| It's specifically DSLs, and the concept is non-Ruby specific.
|
| People that got bit by Chef (which is still great, but it can get
| unwieldy) may blame Ruby, but the problem there was things
| getting much too far away from the actual CLI commands, so it was
| a _DSL_ lock-in problem.
|
| The warning against DSL lock-in may be founded.
|
| But, when it's kept simple, DSL lock-in may not be there as much.
| If you can quickly translate it to something else, you're good.
___________________________________________________________________
(page generated 2021-01-06 23:00 UTC)