Hacker News new | comments | show | ask | jobs | submit login
Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
360 points by dhruvkar on May 18, 2017 | hide | past | web | favorite | 513 comments
I've been programming for ~3 years now, first just on the side and now full-time. My learning has been in stops and starts. Now I can feel the cumulative learning paying off. I'm also realizing there's SO much more to learn. What advice do you have for programmers just hitting their stride?



I have been developing professionally for 20 years and I'm in my early 40s. What I've learned:

* Salary compression is real: most companies are not going to keep giving you raises to match what the market would give you for your skills. They would rather you leave and take all of the institutional knowledge with you than pay you the amount you could get elsewhere. Even if that means hiring someone else at market value.

* Don't get comfortable at a company to the point you're not getting new experiences and learning new skills. Don't become a dinosaur.

* Even if you don't want to become a manager, when the time is right and you have the right skill set, demand a title with "architect" or equivalent in it. Titles are B.S. but people listen to developers with "architect" as part of their title. I insisted on the title and now I'm being recruited for much higher salaries even though I had the same responsibilities as a "senior".

* Good local recruiters are your friends. They can tell you salary ranges for a job and they do a lot of the hard work for you.

* know how to calculate your contract rate if you're doing contract work. Your rate will be different if you are a W2 contractor vs a 1099 contractor. Take into account self employment taxes (1099), the lack of PTO, the time between contracts etc.

* Whether you are a contract or perm, realize that you are still your own company. Your employer is your customer. Do you your best work but never feel a sense of loyalty that keeps you from jumping ship for higher pay. They don't have any loyalty to you.


This is the best advice here. Mostly around

>They don't have any loyalty to you.

Companies preach "family" and "loyalty". DO NOT BUY INTO THIS MENTALITY. They're not going to hesitate to fire you if it means they can maintain their bottom line.

and

>Even if you don't want to become a manager, when the time is right and you have the right skill set, demand a title with "architect" or equivalent in it. Titles are B.S. but people listen to developers with "architect" as part of their title. I insisted on the title and now I'm being recruited for much higher salaries even though I had the same responsibilities as a "senior".

Title's probably aren't going to be given without some other political reasoning. They have to be claimed. Same goes for "Director", "Head of", and "VP" titles. Titles are rarely assigned based on merit, so stop trying to earn them.

Additionally, I'd like to add the following advice:

Don't take compensation as equity these days. It's the same as taking your salary based on lottery tickets. Especially heed this advice for "nothing" equity offers of ~1% of common stock. It takes a really large exit for that 1% to turn into something meaningful for you. AND that's assuming there are scraps left over for the common stock holders.


> Title's probably aren't going to be given without some other political reasoning. They have to be claimed. Same goes for "Director", "Head of", and "VP" titles. Titles are rarely assigned based on merit, so stop trying to earn them.

My god, that's a spot-on piece of wisdom if I've ever heard it. Some titles like Principal and Architect can be earned through hard work and exemplary performance. C-level titles and Director/VP almost never operate on merit.


> >They don't have any loyalty to you. > Companies preach "family" and "loyalty". DO NOT BUY INTO THIS MENTALITY. They're not going to hesitate to fire you if it means they can maintain their bottom line.

Indeed. It's great to love your work and even your job, but never forget that this love is 100% unrequited.


Having to move to get promoted is frustrating and real. Within large companies you can usually move to another team (how hard this is varies), but it is typically required that this be a lateral move, which then slows velocity, whereas changing companies would not normally be a lateral move.

I'm cautious of the word "Architect" — even though I've had it in my job title in the past, and still believe that it can mean something. Unfortunately, it's also a word that's inserted into so many unrelated jobs titles (Enterprise Solutions Architect, Information Architect) — if you need to get beyond senior, and have influence over the wording of your title, then Principal and Staff are useful words — until they too are devalued


Lateral moves inside a large company are a good way to improve a CV.

It is easier to get "hired" for new technology stacks because some people in the company already know you, instead of random HR guy that doesn't care about technologies used in side projects, only what was used on your very last project at work.


Yes. It certainly isn't a one way street. I'd also add that having seniority/tenure has its own value within a larger organization.

There is certainly no one-size-fits-all advice here!


Solid advice.

I'd add one more - if you ever get a good client (freelancing, even when you are full time) keep them happy. A client who doesn't come up with billion changes, pays on time, doesn't micro manage etc is really worth working with, even if the work itself might not be super interesting.


All good advice. After about the same amount of time, I am seeing things from the other side -- that of the manager / employer. I have had quite a few employees who came to me and sheepishly told me they were accepting another offer. In every case, my response has been "Congratulations!" and it's sincere because these people are also my friends. I want them to win! As their manager, part of my job is to provide an environment where they can grow their skills. If they grow faster than the business grows, economics tells me what to expect.

If you tell your employer you're leaving for more money and they get angry (assuming you didn't just consume a bunch of money in training), that's a sign that you made the right move.


Reminds me of something I read:

A manager once asked a director for a training budget for his employees.

His director asked "what if you train then and they leave?"

The manager replied, "what if we don't and they stay?"


> Titles are B.S. but people listen to developers with "architect" as part of their title.

I would be careful with this advice. It might get you a cushy job and a higher salary at bad companies, but I think it's bad for your career in the long run.

In my experience most "architects" don't do any real work while cooking up a bunch of "best-practices" that sound good in a vacuum but either fail completely or create a big unnecessary mess when it comes to actual implementation.

In my experience, real practitioners who are actually worth paying attention to usually have the title "Lead", "Manager", "Director", or "Principal".


I was recently told by manager - who insisted on his title as "director" not managsr - that the title "manager" is actually seen as more tactical and not strategic and has less respect.

I would rather be called a "lead" than "principal". A "principal" is seen as an individual contributor, an "architect" is also usually an individual contributor but could also be someone who interacts with various departments to get stuff done.


I agree. My title has "architect" in it at my insistence, but I'm also the only dedicated developer in the department. So I have to "architect" my own solutions.


All the architects I met at MSFT were (formerly) star devs, and most still wrote some code (and did code reviews).


Where are you at geographically? I've never had good luck with the local recruiters in Silicon Valley, but maybe they're better in places with less info about market rates?


Recruiters are almost universally horrible, but there are usually a few out there in any market that have at least some idea what they're talking about. They are real diamonds in the rough and can take years to find, which makes them even more valuable.

However, sometimes even horrible recruiters can help you get a foot in the door somewhere. This is especially true with temping: you show up and start working right away with a minimal interview process. It's a great way to subvert corporate HR machines and get in the door and start making connections.

If you're looking for a new job of the type that recruiters may have, submit your resume to them and let them spam it out for you, but be firm with them when they want to waste your time by sending you to something that you know is a dead-end, or when they're trying to set up "check-ins" or other meetings that don't have a client/potential employer in attendance (do note that most will want to meet you once to look you over and make sure they won't be embarrassing themselves by sending you to an interview, but once the relationship is established, resist further recruiter-centric time waste).


Atlanta


I am in Atlanta, I would love to connect with a decent recruiter. I have a low tolerance for fools. Msg me please.


How?


old fashioned email works, since there appears to be no obvious way to do it thru our profiles.

moc.liamg AT hcselftrebor reverse that.


>> * know how to calculate your contract rate if you're doing contract work.

If you have to wade through traffic to get to your place of work, figure that time into your rate.


Where "recruiter" = "freelance recruitment agent": there are an awful lot of bad ones, so if you find a good one hang onto them. They're less likely to be blacklisted by employers.


I've never had a recruiter that submitted me to a company without my permission. I also don't post my resume. I only give it to recruiters after talking to them and knowing the company they represent.


Everyone's code basically sucks, including yours. The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning. Learn from your seemingly smarter peers, but don't idolize them. Chances are they will leave the company long before you do, and you will figure out that their coding skills aren't all they are cracked up to be, especially if their code is poorly documented. You will soon understand that they were focusing on getting the job done, while you were expending all that effort to be clever. In that sense, they were totally right.

Don't overwork. Seems obvious, though it's not only still prevalent in America, but more important for our field. Working extra hours has rarely benefitted me either in quality of work or in company treatment. Nobody cares that you put in extra hours. In fact, don't expect your boss to care about anything you are doing even if they are generally benevolent.

Your success is mostly dependent on your personality with appearance as a close second. That's not to say you won't have big wins with the projects you work on, but a lousy programmer won't get fired if they are charming and everyone likes them. The more I refined my social skills, as well as my grooming, the more my minor achievements would get overinflated by my peers and the more they would overlook my mistakes. It's just a cruel fact of life, but at least it's something most people can actually address.


> The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning.

This is really untrue. On the surface, code might look the same between a beginner and a senior developer, but the decisions underlying the code will be night and day. Beginners will solve the problem of the day directly, with no care for introducing complexity and no willingness to reconsider past decisions.


In many fields, it takes a master to make everything look easy. It really seems to be the same with programming.

Coming from the other direction, just because it's straightforward to you doesn't mean it's obvious to everybody else. Try to be patient.


My interpretation is that most of this disagreement is just from ambiguity left by the parent's brevity.

Experience certainly shines bright in architectural and design decisions.

I think the parent's point is that no one's code should be considered sacrosanct; all of us can make mistakes, and all of us, even the senior guys, will end up writing some ugly hacks just to get something out the door on time.

More junior programmers should not be afraid to make a pass at improving something, nor should they try to emulate their peers' styles or behaviors without thinking about and processing them, lest they internalize bad habits. If a junior dev notices an error, they should point it out, instead of assuming the senior developer's code is beyond reproach. They should understand that once they get added to the resident Wizard's project, they're still going to have to deal with the reality of a production application, which means shortcuts, impurities, bugs, and mistakes. The principle of Linus's Law depends on developers who are willing to call out mistakes and at least prompt a discussion about the tradeoffs.

This doesn't mean that senior developers won't be much better at writing maintainable code on a macro level. This is especially true because I've found it usually takes until upper-mid-level for developers to really get an appreciation for simplicity and avoidance of technical debt, and to register that you're actually better if you can do more with less. (n.b.: speeding up a computer program is just making it do less)


That's why comments should mostly indicate the why of a design/architecture choice that was made, not what the code is doing.


Probably unrelated

It pisses me off how I keep having to rewrite/resolve this particular problem I have of deploying a photo sharing site based in a poor network area.

One day I feel satisfied with the work I've just done, the next day it is garbage and I do it again a different way.

Faster but not fast enough.

Then you get this huge block of code and feel this heavy weight like ahhh.... Slash and burn...

Am I doing this the right way? What is the right way? Look at other major sites, why don't I achieve that same performance?

It is nicer to start over but is it a waste?


Ahh, rewrite vs letting it stay! The classic maintainer dilemma!

Answering this really depends. I think I would start with "what do I hope to get out of this process". Are you doing this to learn? Are you doing it to grow a user-base? If it's a user-base, is this the biggest problem preventing your growth? If it's learning, is this the most interesting problem for you to solve?


I'm doing it because the site is too slow where people don't stay/staring at a loading icon. 0.5Mbps and lower is really annoying to deploy a photo-based site gee who would have known.

The Dom loads just over 1 second, but things are still waiting to show up(js?) So I'm thinking of building empty templates like "Hey something is here don't worry."

I don't know. I'm actually not sure what progressive loading is. I currently use that blur-up method but I've seen those sites that use a technique where the photo is super pixelated (large pixels about a quarter of an inch or 1/8) before loading the high res. I think that is true progressive loading but don't know what it means with code.


server side render or put in HTML as placeholder. I've wanted to placeholder images with the primary color or some gradient that can be made in canvas but never got around to it for a project.


I never really understood what that meant. Server-side render it's not template generation? Time to learn how to read.

I do build a template and spit it out according to what is requested, but then a JS function runs to "fill in the blanks" with a secondary call for the missing data. I should probably get rid of the images formatting (based on aspect ratio) to fit into the tiles. I don't know...


> The boundary between a beginner and a coding rockstar really isn't very great

I'll add to the chorus here and say this is not only untrue, but so untrue as to be absurd. By all means caution against hero worship and remember that even those with exceptional talents are human, but don't misinterpret that lesson to mean there are not vast differences in quality between a beginner and an expert.


One thing I know for sure is the enormous difference between myself as a beginner and today!


> The boundary between a beginner and a coding rockstar really isn't very great

I respectfully disagree. My experience says the difference between a beginner and a really good, experience coder, is HUGE, and not only on fields like "machine learning" but in everyday commercial systems.

Unless, of course, your platform is something like Java where everybody is crippled to an extreme degree.

That is, if you get 400 people on a room, tie their hands and their feet, they most likely dance with the same skill, their dancing experience notwithstanding ...


I think an important piece of advice to take from this (and something that I learned early on) is to favor tools that reward mastery. In this respect Java isn't actually that bad, even if there are better options available. What's worse is the culture of many organizations that happen to use Java.


Misapplied Java design patters are the root of all AbstractWordFactoryFactory("evil").


The point he was making is that most experienced coders are focused on delivering, regardless of how slick their code could potentially be and eventually all code will suck.

You just proved this by picking on Java.


Also it makes a huge difference for the next person who'd work on that codebase to add a new feature. Doing that could be anything between a breeze to a blazing nightmare depending on who wrote those codes earlier.


> Everyone's code basically sucks, including yours.

Which is why I'd say, unit-test your code, or TDD, or something. When you look at that crap months later, your mental model of how it all works has completely eroded, and only the test suite is left to preserve your expectations as they existed back then, preventing you from wasting a lot of time stepping on your own toes while you re-grok the big picture, if you have to make a change.

> The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning.

I don't agree with this. I didn't spend 20 years learning nothing, as it were.


TDD seems to be mentioned in a lot of responses here. I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way.

My main thing with TDD right now is - how do I avoid writing tests that are too tightly coupled? I've gotten burned in the past, not even doing TDD, with tests that "know too much" and end up being more hassle than help.

Any good resources on TDD and general testing strategy that anyone can recommend?


> I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way.

You aren't wrong, the state of unit tests in the wild is dreadful. Many were forced into creating tests by management decry, others just think they know what unit testing is. Sometimes the latter are even unit testing advocates.

Remember what a unit is, it's not a class or the method, it's the unit of behavior you are testing. In practice this basically means whatever you are asserting.

Stick to the single assert principle and keep tests small. This doesn't mean only one assert statement, but only one behavior. Often asserting that a function returns an object will one test (it didn't return null), the details of the fields that object contains (like did we format "LastName, FirstName" properly) will be different tests. If you are asserting "LastName, FirstName" in 10 tests then 10 tests will break when that behavior changes. Only one test should break.

Always have a setup method that creates the owner of the unit and any of it's (mocked) dependencies. When a behavior is added it should take less than a minute to add the test for that behavior (assuming the test fixture already exists).

Do that and you're writing better tests than 95%+ of the industry.


Three answers:

1) Just keep going. Experiencing the pain of less-than-ideal tests is pretty much the best way to learn. It also frees you from outdated dogma about testing.

2) Maybe try testing at different levels? I got into testing by learning to write big slow acceptance tests for a particular user experience and small fast unit tests for a particular module. This helped me see what each kind of test was best for. (Maybe your "big tests" are written in Cucumber and automate a web browser, maybe they test an HTTP API, that's up to the kind of work and environment you're in.)

3) Watch this video "Boundaries" by Gary Bernhardt: https://www.destroyallsoftware.com/talks/boundaries


You could divide (in your head) contract and implementation details. Contract - what "unit" should do, e.g. factorial function should compute factorial for given numbers. But how exactly this is done is implementation detail (will be used recursion? do/while loop? will there be result caching?)

The trick is to omit implementation details from testing, because implementation can change, but after all fact(4) should return 24 no matter what.

So it's useful to think in categories of contract given unit should fulfill instead of testing everything for the sake of testing.


You know how you manually test code sometimes in a console, like a REPL?

Automate that and you have a unit test.

Do it right before you write the implementation (forcing you to first consider how it might work, not a terrible exercise), and you have TDD.

Every unit of code should be smallish, focused, and with the absolute minimum of external dependencies. That will make it easily unit-testable and far more maintainable long-term.

There's finally empirical data emerging that TDD is a labor-saving device... Look up the Nagappan paper. (There's more than that now, though, that's just the most famous one.)

Also, as someone else mentioned, watch the Boundaries talk by Gary Bernhardt. Amazing.


Tests and TDD are different things.

I view TDD as a workaround for a lack of a REPL.

When the code is finished, the tests can be written or polished but writing them before any code is just one variation of testing.


The point of TDD is you can define the behavior before writing the code. ie. you define the expected result:

  def test_sum():
      assert sum(1, 2, 3) == 6
  def test_sum_no_args():
      assert sum() == 0
  def test_sum_negatives():
      assert sum(-1, -2) == -3
etc, and then you write the function.

This means you only do the "REPL" testing once ever for each case - and you can rerun the tests for all future changes. If ever type the same function + args into the REPL more than once - you have done redundant work and are wasting your time.

Likewise if you're in the habit of writing tests after your function is made - it shows you haven't put much thought, which means you haven't done the proper analysis of why the function exists, if the function is really one function or should be two functions, what arguments it can take, what it should return etc.


> if you're in the habit of writing tests after your function is made - it shows you haven't put much thought, which means you haven't done the proper analysis of why the function exists, if the function is really one function or should be two functions, what arguments it can take, what it should return etc.

I'd say that's a pretty broad brush you're painting there with


I'm not wrong.


I would say that you are, but you've convinced yourself otherwise.

But testing is important, for sure.


> I view TDD as a workaround for a lack of a REPL.

Every manual test you do of your code in a REPL is literally a unit test screaming out at you that it wants to live in your suite.


Yeah, I started using TDD, and now I sweat over my tests instead of my code.

Same general quantity of perspiration either way.


I agree with your sentiment. I also think of TDD as a way of trying to overcome confirmation bias. I actively try and write tests that might prove my code has bugs. When they don't fail I feel more confident about what I'm shipping.

For me that's the craftsmanship in software development - shipping something I'm proud of.


I'm.just now getting to the point where I'm finding this necessary. Any resources you can point to for a beginner in testing (python)?


Totally agree on the personality and grooming points you made. You need to be good at making people know exactly what you have achieved. Shout about it on slack, fire up google docs and write some brief documentation on a new feature you implemented. Others within the company won't be actively looking at your contributions. They will notice who stands out, who is taking initiative and touching base regularly. Unfortunately this trumps true programming talent in startups - EVEN if you are one of the gods.


If you believe you're one of the gods, you're likely delusional. If you don't communicate well and hold that belief, you're certainly delusional.

Programming talent is useless if you can't communicate. Because your main job as a company grows is to grow the people around you, not cranking out more code. Communication overtakes pure coding skill the moment more than one person works on a project.

It's not about "trumping talent", it's about the fact that communication is part of the talents you need.


Also, ask for the new, interesting work, make designs, talk to others about your ideas - don't just show up with a complex multi week/month solution.

I've never understood why more people don't ask for the interesting, fun, challenging stuff. I've always done that, and been glad I did.


I agree. Its also worth noting that the need to publicise your work should not be taken so far that people perceive you as boastful. So there is a balance, but you definitely can't just be quiet all the time.


A corollary of your first point is that it is code that is bad, and not your coworkers. Code is complex and nobody really knows how to program. (Proof: If folks did know how to program, then we wouldn't fight over which programming language is the right one; it'd be obvious.) So don't ever blame your coworkers unless they're deliberately malicious; instead, have compassion for them and for yourself as well.


>Nobody cares that you put in extra hours.

This is all in the presentation. The point of putting in extra hours is not to get more work done, but to appear at least as busy as (but preferably busier than) your peers.

Most people can't tell if your work is good or not. They can only tell if it looks like you're working hard, and if they like you/find you personable. For most people, "butt in chair time" becomes the biggest factor in their perception of how hard you're working.

Since you're providing good advice about appearance, politics, and popularity, I'm sure you've registered this. We should just clarify for the people who are "4 years in" that "don't overwork" means "don't actually overwork", but do take care to ensure everyone in your office thinks you're a hard worker.


I tell my teams this regularly: you'll hate all legacy code you work with, especially your own. This means, in essence, that you always hate your past self.

Pushing that hate for legacy code to your own self is important, as it as a good motivation to improve (for us narcissists at least).


After having worked in a legacy javascript codebase, I can say it is very much possible to discern between sucky code and code that is maintainable.


That seems like a lesson in corporate culture, not programming. Nothing that you do really matters more than how good you look doing it?


That shipping stable software that works and meets requirements is what people really want. In other words, what the non-tech business people want, or your customers want, is software that fixes their problems, makes their lives easier or makes them more money.

It's easy for us programmers to become fixated on using a newer JS framework, a slightly tighter Java loop or the latest cool language. Took me a few years to realise that even though I care a lot about those things, other people do not. They are interested in the outcomes, not how it got built.

I'm running my own business and building things for myself these days. I use vannilla JS on the front-end and Java 8 on the back. Since I gave up chasing the new cool tech I have built a bunch of stable systems that have been great, well received, products.

If you become someone who has a history of shipping things that work, you will do a lot better than someone who knows how to write hello world in every JS framework.


This. Make your _business_ case, not a technical case. This applies to software engineering, security engineering, etc.

The above comment does not absolve you from doing cool things, it's just that the cool things should align with business interests. No yak shaving. Sometimes writing a one-off script will take 30 minutes, and doing it by hand will take 10. Do it by hand.


Here's my problem.

I'm not particularly prolific, so the number of ideas I have far outweighs my execution so far. This is mostly due to ADHD and other issues which I'm working on fixing, and while contextually relevant is not my point.

This lack of prolific-ness means that I have a literal tower (it's rather intimidating) of wanting to build cute but objectively not so useful routines simply for the sake of building them.

I realize this is essentially the foundation of creativity, but I have a hard time justifying doing these things as I take a very long time to execute anything.

So, the ideas file themselves away - and surface when I'm trying to design actual things I'd like to build. And I get horribly distracted with doing X or Y a certain way, or I get carried away with how I can build Z out like this or that idea I had two years ago...

My problem is focus, I think, and mental partitioning, which I'm not good at. Does anyone have any suggestions for how I can do that?


Personally written organization helps me. I like to use Trello to organize my thoughts. When you get an idea, write a quick note to get it out of your head so you can stop thinking about it. It's written down, you now have the freedom to let go and attend to it later. Schedule specific time to look at that list and put it on your Calendar so you don't forget. "I don't need to think about that right now, I made time on Sunday afternoon to prioritize and pick out which ideas are worth it." or "I will only check my ideas for things to refactor when I have a lull in my schedule, but I'm busy right now."

Also on the tower of ideas-- it's not a to-do list, you don't have to commit to every idea that flies through your head. Your ideas are a great resource for you to reach for any time you need it. A lake of ideas you only need to go fishing in when you happen to want to.


Your completely right, and it's something only someone with ADHD can understand. Depending on how bad your ADHD is, mental partitioning will be incredibly difficult thing to do and that has everything do with lack of attention/focus regulation.

You will have to find a way to develop the capabilities of your brain(working memory, long term memory, task execution and completion, focus and accuracy). You will have to do something that you have been evolved to do which is to have a creative outlet (Dancing, Music, Art) to develop those abilities. There has to be a task where you have infinite focus/hyperfocus, that builds a higher ability. In a sense you don't have to do something that is hard, but something that comes natural and something that grows.

The sequence of steps and motions that are required for dance, movement of muscles to precisely line up with the notes of a song, to reproduce the form of a drawing/painting all require some sort of mental partitioning. These things are all interrelated. I personally have only scratched the surface, because things become infinitely complex I have to decide what is the most important develop. If your lucky enough to be creative and logical these abilities will bleed into each other.


Your "problem" sounds different the one I currently deal with.

My current solution is to have a backlog and spending time to prioritize them. I'd focus on my top priority, and continue writing down new ideas as they come into my mind. When I finish with the top priority, I re-evaluate to find out where the recent ideas fit in. I'd also look into reading about the agile methodology.

If you're like me, ideas come in very frequently. Embrace your creativity and ambitions by logging them. But try and shift your mindset to thinking about what is actually necessary for the final product.


Also, "freeze" your "features" at versioned levels for each project.

If you want to add or alter something, that would be a new project.

Otherwise, you will never finish a project.


eg. "Sprints" in Agile


Like the work you deliver to your boss or client, there is a Final Product.

And yes, Agile is the best, because it's of the mindset that the Product is iterative!


ADHD sucks. I have it, too, and I somewhat solved this problem by moving into R&D, where they pay you for ideas directly. But these fields are rare (quant finance is one of them).


I also have ADHD which has reached debilitating levels at times. Noise cancelling headphones, removal of computer games, and being disciplined has helped. In all seriousness though, it's a more complex condition than most people realize and seeing a specialist is never a bad idea.


This! and know why you are building what you are building.


I printed this XKCD specifically to remind myself that some things aren't worth automating!

https://xkcd.com/1205/

On the other hand, sometimes you're automating for reasons other than time savings. Maybe reproducibility or auditability.


Or the fact that the task is so mundane/boring/annoying/irritating (pick an applicable adjective) that it's worth it to you to spend a day automating it so you never have to do it again.


Great point - the benefits of automation can't always be reduced to time saved per operation. I wrote a blog post [1] about this in response to that xkcd.

[1] https://andrewstahlman.com/posts/IsItWorthTheTime.html


The problem with that is if you make a mistake the first time, then redo it by hand, you have used up 20 minutes. Made a second mistake, and you are even with automating it.


also keep in mind: https://xkcd.com/1319/


I agree completely with this post but want to provide some additional insight that I've gained:

Learn to enjoy your work as that's the only way you'll make it long term. If that means spending a little extra time to write an efficient algorithm or structure your code efficiently v.s. just "getting it done", then do so for your mental health, not for the company.

You see, we're craftsman at the end of the day. We all want to feel like we are contributing quality work, and often that conflicts with the business's priorities. Take pride in your work and you will find it easier to show up at the desk each day.


This is why I always ask what is the business value of doing cool thing X on a project.

Using your words if "using a newer JS framework, a slightly tighter Java loop or the latest cool language." doesn't improve the business value of what the customer is getting out of the product, it gets a very big NO.

I became very much against "cv building driven programming".


Along those lines I'm always surprised at how many SUCCESSFUL tech companies even today are built with PHP. Tech stack is often not the driver of success or failure in a company.


Besides, PHP is a mature and very well working technology. Not shiny, but otherwise very good.


There's a balance to be struck there, though, and pejoratively referring to the seeking out of ways to improve as "CV driven programming" probably isn't the healthiest attitude out there. If you're not doing new things, you run a very great risk of sitting in a weak local maximum. Don't fix what isn't broken--but you need to be stretching out, too. Not doing so induces a sense of stagnation to a team and can chase off developers with ambition (which you can and should harness) and a sense of quality.


I agree there is a balance to be met.

For greenfield applications, chose whatever the customer ask for on their Request For Proposals, or suggest modern solutions if they leave it open to proposal reply.

On existing solutions, deployed for several years on the field, actually measure what it brings in regarding business value. Either in terms of reducing project costs thus improving profit, or improving customer UI/UX thus improving the value the customers get out of the product, specially if it helps them to improve their profits.

What I am against is just adopting tech that doesn't improve anything, sometimes even causes products to be abandoned or removed from the market, just for the benefit of a few devs improving their CVs.

I have taken part in a couple of projects where it actually happened. Architects were busy chasing the new shinny instead of delivering what customers actually cared about. In the end the product was canned.


> What I am against is just adopting tech that doesn't improve anything

How do you know what improves what if you don't use it in anger?


Pilot projects, technology analysis, market research, reports from external consulting companies, architecture assessments, university projects,....

There are many ways to research new tech without touching the current product development.

Sometimes it is better to be the turtle than the rabbit.


There are plenty of cases where new frameworks come out that allow you to move forward much more rapidly as a dev team. They allow better testing, better code organization, etc.

Especially in the Javascript world, it's such a new field that new techniques are being invented regularly. I've seen old backbone applications that are essentially frozen in time feature wise, because the code is so cumbersome and coupled together (by the framework's design) that it becomes impossible to add new features without having to refactor/rewrite the entire thing.

I agree, if you have have a finished product that won't be getting many new features at all, then leave it alone. But if it is an ever evolving product with new use-cases and features being dreamed up regularly, that application should probably be re-written many times over.


On JavaScript world, old techniques and architecture lessons are being rediscovered every day. There is hardly any invention going on besides JIT compilation improvements for dynamic languages.

As for CV driven programming, here is a real case from a long gone project.

Dumping a fully working and battle tested Perl scripts for application installation in several flavours of UNIX, for Groovy based ones built on top of Grails.

It really improved the business value of those customers having to deploy a JVM, executing scripts slower than before and what was a simple set of CLI commands turned into starting Grails and navigate via web pages uploading files.


I strongly agree.

However, there are special cases where you are exposed to a new technology which enables new outcomes.

I was fortunate enough to blunder into using the Web in '92 and Java in early '95 and they were tools where the "how" did matter quite a lot...

[NB I haven't touched Java in a dozen years or so]


Also there are differences in further employment perspectives.

I mean if you have a problem to solve and you have a choice to use some old tech that you already know, but it is going out fashion, and some new one, then the choice of the newer one improves your employability in the future. For example, I guess in 2000 there was not that much people with 5 years of experience of using Java in production, but those who had it, had to have pretty good chances to easily find decent job.

Of course there is a risk to bet on wrong technology, but at least you keep learning instead of just using ageing tools and becoming more and more disconnected from the current state of the art. It can be as scary as this https://news.ycombinator.com/item?id=11886753, a story of a guy who successfully solved business problems and delivered products with jQuery for a long time and then eventually found that he was out of demand because businesses started looking for people with experience of using React and he didn't have it.


That is true and can be a problem when recruiters just keyword match technologies from your CV.

When I've recruited I've always tried to assess the candidate on ability to get things done rather than knowing a specific framework. I'd look at how deep their knowledge goes and see if they can ship stuff - if they've been using jQuery but I need React then I'm not too fussed if they've shipped quality products using jQuery and have taken the time to learn pretty deeply how it works, the keenness to learn and ability to build things should easily translate to React and I'd rather have this person that someone who has skimmed the top of React for a few Hello Worlds.

I would hope and prey that interviewers would take a similar approach, if they are just ticking off keywords from your CV then it's a pain.


I find it funny that you felt the need to distance yourself from Java.


Are you using a java framework on the backend? Something like Spring maybe? I'm just curious, I've been thinking about using Java for the backend of my own projects.


I have used Spring before and I like it quite a bit. I have tended to use vanilla Servlets for most of my projects recently and use libraries like Gson, Apache Commons, PdfBox etc etc where appropriate.

I think if anyone wants to go down the route of using Spring, Play or similar then you MUST spend the time learning it in pretty deep detail. I've seen so many people with "Spring experience" on their CV who can make a webpage appear using the tech but as soon as something goes wrong or they are asked to do something a little different they are screwed as they don't know the framework well enough.

I only use vanilla Servlets and my own stuff because I have been building up my own libraries and ways of doing things over time and I've been burnt enough times with old-school frameworks (like JSF and Seam) that just add so much unnecessary work and ball-ache.

I like to write the fewest lines of code possible and also use the fewest dependencies possible. I find that plain ol' Servlets gives me that for most of the stuff I do.


I appreciate the reply, thanks!

Perhaps I will try to use vanilla servlets for one of my personal projects. I'll have to start reading the docs!


I wouldn't suggest this sort of self-damage; I've been there and I've made the mistakes. Servlets, as written, are lousy abstractions for HTTP. Worse, where the abstraction breaks to expose HTTP to you, it doesn't really do much in the way of enabling you to do anything you couldn't before.

If you want to use the JVM, one: use Kotlin over Java, it is a strict superset and a better development experience across the board. Two: evaluate something like Dropwizard (or even Spring Boot) well before you go near servlets. JAX-RS is not perfect, but it's a lot better than whatever you will home-roll. (Again, been there.)


I have to agree with parent heavily and I used to be a long time Spring advocate since version 1.0.

The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose.

I used to to think this was a terrible thing but these days I think using less dependencies, autoconfigure magic, and even using older technologies such as the Servlet API are just easier to maintain, understand, debug, stable and surprisingly easier to train new folks on.


> The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose.

This doesn't match my experience at all. Only really ossified organizations get to this state, even in Java-land. The amount of abstraction I have needed to put on top of Dropwizard in order to do literally everything I've ever needed, from websockets to web pages to file service. The underlying Jersey and HK2 system is simple, well-documented, and straightforward when I've needed to extend it, but these extensions are restricted in scope and easily testable to boot.

I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.


I think you may have misunderstood me a little.

I'm not saying go use the Servlet API directly all the time but you damn well should know it since almost all the others build on top of it (including most of Jersey).

Particularly Servlet Filters. It seems like every framework has their own take on onion processing a request but servlet filters are actually easier to write then say some Spring framework "Advise".

As for Dropwizard... You do know its built on top of all the new JEE stuff like JAX-RS. I am willing to wager it will die and be replaced with something else... but those underlying javax specification stuff (like JAX-RS, servlet api, etc) are still going to be around.

You should know those underlying standard APIs.

The funny thing about you mentioning Dropwizard is it basically started as someones else stack built by mixing standard libraries.... something companies do all the time.

> I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.

Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel.


> "Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel."

This.


“A reminder that the goal of a given computer program is first of all to meet some business requirement may come across as a platitude. In practice, the excitement of technological challenges often slowly causes attention to drift from the end to the means…”

—Stephane Faroult, “The Art of SQL”


What application server do you use for the backend? Tomcat?


Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost.

Solve real world​ problems. Doing elegant things is very difficult because the real world is much more convoluted than theory.

Do a few things in depth. Don't jump at the latest thing every few months.


> Work somewhere where software is the main product and not just a cost center.

This is THE big difference between S/W dev and IT. For 20 years I worked in the former, and for the past 10 in the latter. No question about it: IT is hell. Theirs is a never-ending mission to reduce the cost of moving data and being "compliant" with often-meaningless ever-excessive corporate standards (and forever meaningless MBA/CIO fads and groupthink).

Worst, in most businesses, IT doesn't have a respected mission. Ii provides an infrastructural service (a cost center) that other C-suiters dis as no more important than HVAC and sewer. IT appears on their radar in only two ways: 1) when something breaks and info clogs up or stops moving, and 2) when the budget is revisited and interest in IT cuts are reinvigorated.

Since nobody else in the corp. respects IT's mission, senior mgt. compels the CIO to adopt meaningless surrogate goals because IT's actual mission isn't sexy enough. So for the next six months IT adopts "Platforms" or trains half the staff in Six Sigma, or outsources, or insources, or promotes of whatever other CIO groupthink initiative is in vogue at the moment.

So yes, work somewhere software is valued, unlike IT.


Having regrettably started from the IT side, it's seemingly impossible to make the jump to a software company proper. Nothing I do day-to-day is flexing any mental muscles an interviewer would find sexy. We're like a permanent underclass of undesirables. Without spending time outside work to focus on sharpening basic undergraduate CS knowledge, I know I'm getting objectively rusty at the types of problems I actually do have some remaining passion for.

I fear I'll be hammering out poorly-spec'd features to the beat of another department's Gantt-chart for the rest of my life.


If you want to train yourself in programming, algorithms and understanding of time complexity, I recommend giving codility.com a go. You are asked to implement solutions for various problems in a programming language of your choice. Basic literature is provided, for example problems which are elegantly solved with stacks come with a pdf about stacks, their implementation in Python and so on. If you go trough the lessons in the order, you will learn many useful programming techniques, and big O notation will no longer sound scary.

The website provides a decent in-browser editor, or you can write in your own and paste the solution. You get a few data points for expected output, can write up to 10 of your own primitive tests (although I tend to use asserts). Your solution is automatically evaluated afterwards, because it has a bunch of unit and performance tests written for it. When your program fails on small correctness tests, the website says what was the wrong output and what the correct output should be like. VERY nice.

The language used to describe problems is a bit obfuscated and maths-like, but I treat that as extra challenge. You certainly don't have to remember much from your university or high school to get started. It is important to understand and rephrase what they are asking of you.


I sympathize. Early in my career I landed a job in a small software company. My skills improved greatly. Then I made the mistake of taking an IT job. That IT job rolled into another and another. While I stay near the technical top in my IT departments, I find it tough interviewing for software company jobs. The concerns of a software engineer in a software company are just so different from an IT developer’s.

I interview for backend engineer jobs. I notice a common theme in the interviews: efficiency. They are very concerned with transactional throughput. They optimize everything from the services layer to the database for trimming every microsecond. At a past interview, the people wanted me to talk about the efficiency and implementation of various data structures: nothing exotic, just garden variety queues, stacks, lists, and hashmaps. They quizzed me on threading issues. One guy got into various indexes in a relational database and then jumped into TCP vs. UDP questions. In my most recent interview, the guy started by asking me the difference between optimistic and pessimistic locking. In my IT job, I never deal with locking issues: they are all abstracted away. Two-thirds of the way through the interview, I remembered and circled back to the question. However, the damage was more than likely done. A person who deals with those issues daily would never forget. But, I know what to work on for the next interview.

I understand your predicament. It’s deadening on every level when you’re doing work beneath your capability and interest, but you don’t have the necessary knowledge to get through an interview for more interesting jobs. Hopefully, the observation I made above helps you to target particular areas to successfully navigate an interview.


Find a place that will quiz you on real-world work instead of CS textbooks. There are a lot of them.

Companies who base their interviews on CS curricula generally just end up only hiring people who've graduated recently enough to remember it (i.e., their staff ends up being junior because they're selecting for something that's, ironically, an anti-indicator of experience more often than not).


I agree that trying to get stuff done after work is often a non starter. But, I find you can do a lot with one weekend a month of real focused effort without burning out or feeling much pressure.

Alternatively, just put yourself out there. You don't need to be great, just find a job a little closer to your goal.


Honestly, the amount of empathy here is encouraging. I'm not in the best position to take all the advice given just yet, but knowing I'm not completely surrounded by sharks is reassuring.


I have a background in Electrical Engineering, and six months ago I made the jump into my first pure software role. I worked up to it, doing lots of projects on my own time. Just a data point, that if you want to get somewhere you have to start wherever you are.


Would you think that it's not sexyness, but applicability? What values do you bring to the table that a SW company would need?

Because I bet you that you could find some if you switched from targeting straight dev roles to something else that is part of a SW org.


Other than time spent programming on platform X, I'm at a loss as to what values I'd bring. Would I hire myself, based on my job history? Probably not. I'm hardly going to impress anyone with such an attitude!

Any suggestions on alternate roles to look for? I'd worry that just because it's a software organization, it doesn't mean I wouldn't be filling their own version of cog in a cost-center.


I guess this varies by location, but on average there are so many more openings than there are developers that it shouldn't be at all impossible to find a company willing to take a chance on you, especially if you are willing to either work very hard or take a slightly under market value paycheck (for the very first job).

So time spent using X is great, but just saying "I can learn" and giving an example of how you're able to learn is often enough. Then just look at X enough that you know the gist of it, have a small little sample project in your github account, and you'll be good enough that someone will hire you.


Yeah, pay grade is really where it gets sticky. If you have basic skills you can find an entry level gig easily... as long as you're willing to take a market-level salary for that role. A lot of people who've spent years building a career in a dead-end sector will have salaries substantially higher than that, and that makes it difficult to jump.

These people should focus on improving their credit, cutting expenses, and building up savings so that they can take the salary hit that will get their careers on a better track for the ~20 years until they're eligible for retirement.

Alternatively, these people can go in through a social backdoor. Befriend a powerful person at a company you'd like to work at and demonstrate why he needs you. If he has authority to set salaries, he will likely do everything possible to accommodate your higher-than-market salary, even if he can't get you 100% of the way there.

But beware: overpaying an employee is the best way for a company to trap him/her. Do everything possible to not become dependent on a rate you can't easily command somewhere else.


There is tons of middle ground between IT and "proper" software company - for example, banks, while not being tech companies, are nowadays operated via lots of sophisticated software, not unlike say Amazon (and BTW you could argue if Amazon is a retail company and not "proper" software company).


maybe sign up for triplebyte and let them figure it out? nothing to lose


quit your job and use the downtime to retool the way you think. you won't have much success otherwise.

no pain, no gain.


Marc Andreessen argues [1] that this will soon have to change.

I work at an SV software vendor which sells to big enterprise IT groups. From what I have seen, firms are starting to take their IT groups more seriously.

[1] http://a16z.com/2016/08/20/why-software-is-eating-the-world/


Right, so many companies, such as in finance/banks are really going to have to get on with changing that mentality to compete with new or existing competitors who are more tech savy.


"senior mgt. compels the CIO to adopt meaningless surrogate goals because IT's actual mission isn't sexy enough. So for the next six months IT adopts "Platforms" or trains half the staff in Six Sigma, or outsources, or insources, or promotes of whatever other CIO groupthink initiative is in vogue at the moment."

That describes exactly the IT department in my company.


I've noticed this even walking around at work in different areas other than where I sit.

"Hey aren't you in IT can you help me with my computer issue"

One of the things I dislike the most is being referred to as "The IT Department".


I am now in Telco

The only place where I've seen IT being highly respected.


> Work somewhere where software is the main product and not just a cost center.

I've done both and I can't say one is better than the other. I've worked on software products where marketing couldn't figure out how to sell it and kept changing the core functionality. Or where the CEO kept shoving his ludicrous ideas onto development. I've worked on rewarding IT projects where I worked very closely with the users and was very happy to see my work help them perform their day-to-day jobs. I've also worked on slog IT projects where the users had no idea what they wanted and we kept churning.

After 28 years, I ended up preferring working close to the actual users.


"Marketing...kept changing the core functionality" "CEO kept shoving his ludicrous ideas onto development"

Check and check. There's also my personal favorite: marketing informs the dev team they've just inked a big contract with a tight deadline for features that were never discussed with the dev team. "We kinda told them we already had those features but hadn't released them yet. Can you guys build that real quick like?"


Classic. Our supports operative just happened to promise full IE support (we promise only Firefox) just like that.


Interesting! I switch very early in my career to working for product companies because I saw no other way to have a rewarding career as developer. So far it's worked out pretty well for me.

However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers.

My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business.

[0]https://leanpub.com/developerhegemony


The problem being that no one can actually define what agile actually is. (Or rather everyone can, but there is no consistent definition).


Yep, it's a problem, and adding my own "what I think agile actually is" would only add to the noise.

However, I do think that the original signers of the manifesto were onto something. My recommendation for people is, rather than learning an official methodology, that they go and read the writings of the various different signers. Get an understanding of what it meant for them at the time that they signed the manifesto.

Martin Fowler has commented that one of the other names they thought about calling their movement was "conversational software", in the sense that software development process was an ongoing conversation between the developers and the users of the system.

The point I gleaned from the book I mentioned was that (in the general case) the power politics of most IT organizations prevents the development process from every being a real conversation.

As I understand it, many of the signers were independent consultants at the time of signing (or helped lead IT consultancies) and could speak the language of business. It seems to me that perhaps this put them in a more "peer" relationship with the business stakeholders, and allowed the development approach to be more conversational.


> After 28 years, I ended up preferring working close to the actual users.

This is key.


this! but also note users and access to them is what "IT" have and "software" often struggles with. Run some field trials, do interviews and field visits to support requirements analysis...


> Work somewhere where software is the main product and not just a cost center. > Doing elegant things is very difficult...

These are great! I would also add: be certain that the organization shares your values. If you really care about code quality, elegant solutions, etc, you'll have a frustrating time working at a company that doesn't prioritize those things.


I agree with all of this and I think there is a third category of job where is software is neither the main business, nor IT.

Once you have developed the necessary software skills in a "software house", in my experience, the best thing to so is to get stuck into a particular domain, where the company needs software developed (not IT), but is not the main business. These jobs and contracts attract the best $, but also in my experience, highest job satisfaction - you are not just a cog - well, less so, IMO.


If you want to distill it to one factor it's to make sure you and your function are a respected part of the company and not just something that's easily replaced. If you are in that position usually the $$$ is good and the work is interesting.


> Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost.

Very true, but the company culture also needs to be right in order for this to really take hold. There's also the fact that the work and schedule will likely be more demanding. This can be a positive if you enjoy the work, but a big problem if you dislike unpredictable hours. When the company's primary revenue source is software, you will have to work extended hours at some point or another to solve critical business issues.


Depends on what you want: if you work at a company where software is the product (or the service), it can be harder to make the case for releasing software as Open Source. If you work at a company where, say, hardware pays the bills, that can make it far easier to make the case for releasing software as Open Source.


> Work somewhere where software is the main product

So a software company as opposed to working in an IT department - programming and solving problems that really _aren't_ interesting?

That's one of the main things I crave these days (and I think it would make a big day-to-day difference) is to work at a software company as opposed to a company who leverages software.


Agreed, though I'd modify "software company as opposed to working in an IT department" to "work on something profitable". :-)

I don't work at a software company, or even a traditional "tech" company, but I write the software that powers our most profitable product. Since I'm the odd-man-out, and the higher-ups love org charts, they stuck me in the IT department. Net effect: IT just became a profit center and everybody in the company knows it.


> something profitable

Would that be the primary product of your company, or something that empowers other employees to work faster, and push _their_ products more easily?


Personal preference. In my situation, it's a retail product at a company that has a lot of other retail products. The one I work on just happens to be very profitable, so it gets a lot of attention. But I'd be very happy working on the empowering problem you mentioned too.

I've been blessed by having experience in several, very different kinds of applications (web apps to avionics). Over time, I've realized the specifics of the problem at hand are more-or-less irrelevant to my happiness. I'm looking for something that's sufficiently technically challenging, where I can be surrounded by honest, friendly people, and make decent money.


> I'm looking for something that's sufficiently technically challenging, where I can be surrounded by honest, friendly people, and make decent money.

This is very close to my real goal as well - but CRUD apps seem like the norm lately :(


Without internal billing, only the first thing (profits from products) is measurable, and the second thing is mostly invisible.


It's even a money/salary issue. There is a huge difference between the CEO seeing you as someone who makes money for the company as opposed to just being an expense.


Automate things and make people's jobs easier. Then you're valuable.


That's reducing costs rather than increasing revenue. Of course, within a limited range they are equivalent but you really only have respect in a lot of organizations if you contribute towards the latter.


Odd - because margin being what it often is a dollar saved is worth three/four... ten... ?


>It's even a money/salary issue.

Does this mean that you salary isn't increasing, or that you aren't valued at all?

I'm curious how most people receive or handle (or if raises are even a thing)


You want to be in a profit center, not a cost center.


I worked in the IT department of an early software company (est. 1980) based in the Bay area.

It was slightly better, since people understood software's value, and Ops was shared between the devs and IT. However, maintaining that sort of culture always felt like a constant battle. Management often slipped into IT = cost center.

In fact, my job officially became bridging this gap as an IT Business Partner. I don't think I did a very good job.


I didn't think I had an answer for this thread, but this is it. After many years, I finally found my way into a software company. It's weird here... I don't feel like everyone is mad at me all the time.


Couldn't agree more.


There is no future in software development as a job. Move to a management position quickly, network, make friends with decision makers, don't spend too much time on crafting your skills, your reward for perfection will be more insane work and crazy interviews where one part not 100% done kicks you out. Work on your appearance, kiss up, lift, dress properly, use anti-aging cosmetics, make cool looking hairstyle, wear objects of power (like rings), work on your voice, make yourself seen by making presentations, even if pointless and/or stupid, do some trendy thing on a side and show everyone, appear confident at all times even if you have no clue what is going on. Demonstrate your skills by getting an MBA, PhD (even if from a crappy university, it doesn't matter) or a respected certificate. Basically, don't hack computers but people around you. Our field has shifted from meritocracy to over-politicized field, if you are a male you'd in addition face 50/50 gender ratio split pressure and given how few women are in our field, you'd compete for less than a half the available spots as everyone now wants to compensate this ratio in their mostly male teams.

If you really need to make software (like I do), make your own company and license/sell your work instead for >500% more than what would be your salary.


This is like reading advice from an alternate reality. Almost all the VPs, senior managers, principals, etc. that I've encountered in my career are poorly-dressed nerds, not ring-wearing, macho douchebags. If you are a politician in software, you will eventually get found out by someone competent and get the boot. The only way you can succeed as a politicking fraud is to hop jobs every-time the people around realize you can't actually do anything, or ride sinking ships.

Even if some completely broken companies, this was good advice, it would be a recipe for a pretty pathetic existence.


I agree it's a pathetic existence, which is why I am stating it plainly here as our field is becoming exactly as "any other field" quickly. You'd be surprised what goes on behind the scenes at the top level of most tech companies... Most boards of directors are comprised of non-tech members, bringing their own distortions everywhere. The only force we had was the pace of innovation, and that is no longer happening so massively in software as we reached the end of Moore's law, and only few bright spots are still on like AI/ML/robotics where companies can't afford to cross the "bozo event horizon".


That's just not my experience at all. But clearly, it's been yours. Perhaps there are two very different sides to this field, in which case my advice is to keep looking if you find yourself on the wrong one.

From where I stand, software engineering has been an absolute boon. I have friends who are doctors, lawyers, consultants, traders, writers, salespeople, marketers... On nearly every metric -- pay per hour, amount of bullshit I deal with, variety and interest -- my job beats theirs. I started coding when I was 10 years old because I was a big nerd who wanted to make video games. I never, ever thought I'd make a top 3% salary 5 years out of college doing something I love. I'm tremendously grateful for that. I've been really successful by just being good at what I do, and that's mostly what I've seen other successful people do around me.

At the end of the day, unless you own your own labor, someone else will be profiting off of it. The lower down on the ladder you are, the bigger the gap between the value you produce and your income. But that being said, software is not such a bad place to be relative to other fields.


The same for me. I've never seen much politics. It got bad once with an ex-IBM manager, but otherwise it has mostly been about how to get stuff built that meets customer requirements.


>Basically, don't hack computers but people around you.

Ding ding ding! I agree with most of your advice, but this is the heart of it. People are very basic machines. Your job as an employee is ONLY to a) make your boss feel good and b) make your boss look good.

Protesting this is simple naivety. The sooner you internalize and accept it, the better off you will be. I have met multiple men who've lost everything at retirement age because they were naive and allowed themselves to be lulled to a false calm by slick workplace politicians. These events are _not_ pretty.

In software, there is a natural merit barrier to performing even the minimal job functions that can allow us to confuse it for a meritocracy. This is why slick MBAs are reluctantly forced to accept people with basic hygiene problems inhabiting corners of their offices. But mistaking this for actual respect for merit is fatal faux pas.

This is a simple reality that most of the rest of the world was forced to accept during their first jobs out of high school. Software engineers are spoiled, and far too many of us allow it to go to our heads.

>There is no future in software development as a job.

You're getting some push back on this because it's not really universally true. It depends on the individual's goals and ambition. You absolutely can spend 30 years as an employed software developer if you're happy with where that leaves you (and a large number of people are, and there's nothing necessarily wrong with that).

However, if you want to be more than an employee/pawn, if you want to make decisions, if you want to get more than a pittance of the proceeds -- you must accept and realize that your field of operation must be human psychology, and it must be correctly applied in its various forms (politics, marketing, etc.).

The sooner this is accepted, the better. Literally just in the last couple of weeks, I watched a multi-million dollar company with dozens of employees get wrested away from a competent (if complacent) engineer by useless, image-obsessed political hacks.

The kicker? That's not the first time it's happened to him.

Do not let the small successes that people are forced to give based on merit go to your head, or you'll end up like him.


This is some of the worst advice I've ever seen. Do this if you want to die sad and alone with nothing but your money beside you I guess.

The last sentence is actually not bad advice though.


It used to be better, now if you aren't running your own software company you are treated as a 3rd class citizen and you have to become sleazy "Saul Goodman" to prosper. I am super disgusted by the state of affairs right now, which is why I am running my own businesses, but don't expect this would get any better as the computing tech innovation pace has slowed down to a crawl, stabilizing existing power structures for the next 50 years.


I guess it depends who you work for. I prefer to work at small new companies until they get off the ground. Then I shift to the next small new company. Small meaning < 30 employees for the whole organization. Pay isn't as great, and the work is definitely more under pressure, but I find that the only thing expected of me is quality work. I don't have to worry about trying to climb ladders or schmoozing management. I understand that not everyone has the skill set to do what I do, but I think that if you're tired of Mega Corp social engineering, taking the pay cut for more personally rewarding work is a great path to go down. After all, quality of life has very little to do with what you have beyond a certain threshold and more to do with what you make of it. I get paid less than other developers in my area, but I work entirely from home and I choose the technologies, architecture, language, etc.


I actually tried them all, ranging from megacorps that were darlings of techies and Wall Street to nimble startups with amazing tech. It was politics everywhere, at startups even more nepotistic/cronyistic than in megacorps (e.g. seeing a wife of a cofounder and CEO wasting money on getting selfies with some marketing pseudo-celebrities instead of doing real marketing, and knowing I can't say a word because she basically controlled her husband).


What you said resonates with me. I would like to talk to you in detail. Can I PM you?


This is both cynical and exceedingly true. It's something I totally missed early on as a naive developer-puppy who just assumed that doing a good job was enough. The politics tend to be even worse in smaller companies where everyone knows everyone and it's harder to carve out your little corner of expertise and hide/ignore the drama.


Maybe this is true, but plenty of big companies are hiring tons of engineers... so I don't know how this is true universally.


> There is no future in software development as a job.

Wrong. I've been at it for 30 years. It's not all roses, but it's still pretty good. The key is to be doing something where 30 years of experience is worth more than 5 years of experience. I'm in embedded systems, and the experience matters there (to enough people, even if not to everyone). Web programming? I'm less convinced that it matters there.

> Move to a management position quickly...

It is my explicit career goal to never become a manager. I've seen what that looks like, and I don't want it. I might make more money if I did, but it's not worth it.


At some point your brain stops working, you won't be able to compete with fresh graduates, the capability:wage ratio will be very low in your case; you'd get a prompt boot, never to be able to be employed on the same level again. Experience in our field has negative value and unless you get another M.S./PhD every 10 years to demonstrate you are still on top, you are toast.


False so far, and I'm 55. I kick the rear end of fresh graduates. They can type a lot faster, turn out more lines of code per day. Great. I don't write the bugs that they write, so I don't have to take the time to find and fix them. I don't make the design mistakes that they make, so I don't have to fight the design flaws to get things done. They work harder; I get more done, and I get paid accordingly.

And if you think that the answer for "your brain stops working" is to go into management, all I can say is that I'm glad you're not my manager...


You are probably in 1% of lucky ones. Imagine you have a bad year (sickness, family issues etc.) and you don't have management that is used to you around (e.g. there is a reshuffling). How long would you manage to stay? You should put this into your equation. I also dislike being a manager but I am more capable manager than all managers I've been under (maybe I am just unlucky but I don't think so). We all know the best teams self-organize and don't need managers, yet all companies enforce some power structure around to keep control, and reward mainly members of that power structure.


> I also dislike being a manager but I am more capable manager than all managers I've been under (maybe I am just unlucky but I don't think so).

In my case, I'm pretty sure that I wouldn't be better than the ones I've been under (maybe I would be better than one or two, but not the majority). I'm also more likely to get fired as a manager, due to a tendency to say what I think.

If you're a better manager than the managers you've been under, you may be of more value to your company as a manager (even if you hate it). I may be selling myself short, but my value as a manager could be less than zero...


Software companies are about power structures more than they are about software.


Where I come from ppl your age get downsized and replaced by younger employees with less pay. The +50yo will never get a job but is still +15 years away from pension. At the end of tge day only the money matters. You can't pay rent on "job satisfaction". Neither can you eat it or retire on it.


In my experience, fresh graduates may (arguably) run faster, but they don't know which direction the finish line is.


> At some point your brain stops working

Yes, when you die.

Children are much better at learning new spoken languages, but by your logic no adult should even bother trying to learn a new spoken language.


This is very cynical, but not basically wrong.


> wear objects of power (like rings)

The "one ring to rule them all" approach...


I absolutely disagree.

    There is no future in software development as a job
How can you make such a blanket statement? Software is a more lucrative position for more people now than ever in history. You want to be a manager?? Who will you be managing?? Programs that write other programs??


Programs will write other programs, there is extensive work on this problem in progress with some nice low-hanging fruit available in research already. The future will need genius-level swengs only, all mundane/boilerplate/lookup tasks will be done by semi-automated systems and most swengs won't be needed anymore. I am working in this field and can clearly see where it goes and we finally have means to accomplish it within 1 generation. If you aren't involved in AI/ML/robotics, you are going to be most likely sorry, fighting for low-income developer jobs for those that can't afford automation tools.


We go through this once a decade. The problem is a fundamental byproduct of the disconnect between humans, to whom mathematics and logic are foreign concepts that take consistent work to internalize and apply, and machines, for whom ambiguity, context, and perspective are foreign concepts that take consistent work to "internalize" and apply.

Call me a philistine, but I don't really believe we will ever get the natural->logical language mapping perfect enough to obliterate the need for developers on a massive scale. New languages beget new possibilities, which companies want to employ people to exploit, and so on.

Higher-level languages have "obsoleted" the task known as "programming" over and over again, to the point where there will often be 4-5 "automatic programming" layers between the code written by a person and the code that a physical machine executes. It's been 35+ years since your average developer would write machine code directly (i.e., without depending on an "automatic programming" environment (aka "a compiler") under the covers).

There will always be a need to translate natural language into logical language.


The thing is there was enormous progress in natural language processing lately; it's now conceivable to enable some simpler forms of programming using your voice commands only (imagine webapp or mobile app builder controlled by voice) that would satisfy needs of 95% of population, putting many companies out of business. Even at top 5 companies there is a panic about it and many managers will tell you in private they personally think in 10 years there won't be many high-income sweng jobs unless you are in ML or related field, as they see demos from their research labs.

I guess we will see how this pans out in the end...


The thing is that no matter how good NLP becomes, natural language is inherently fuzzy, just like humans are inherently fuzzy. Human languages do not provide the precision that a computer must have. It is possible that the computer can learn to guess correctly in some percentage of cases, perhaps even a very high percentage of cases, but it can never be more than a guess because that information is simply not expressed in conversational English (and I'm monolingual, but I assume it is pretty much the same in other human languages).

Perhaps we are moving to a day when all programming will occur verbally, and each programmer will be paired with an Echo which he verbally instructs as it writes a program. But we will still need a person who is assigned with converting natural language to machine language, including reading in the contexts and assumptions necessary to make assumptions that are almost always correct.

That's the part that I don't see how computers are ever going to be able to beat humans on. You can't squeeze blood from a stone, and if the data isn't there and isn't in any of the spied-on data collected by all the listening bugs all over the house and all the location bugs carried in a person's car and pocket and all the network bugs on the person's computer and ISP, and so forth, the computer won't have the data necessary to furnish the desired response.

Conversational language will not have the necessary precision without special effort being dedicated to expressing ideas in a logical, mathematically-valid way. The people who expend that special effort are called "programmers".

IMO the only hope of a programmerless future is one where the language has meshed to the point that every conversational statement is a valid program after the NLP's macros have been expanded or whatever, and the computers understand this with a 0% error rate. A world where a master programmer reprogrammed human language to be computer-native. I don't see us getting there.


It's like LEGO - you have some basic building blocks and you can compose some cool things with them. Your first LEGO set has only 3 different blocks, but nevertheless you make some nice tools just with them. Then some smart person adds another 2 blocks later. Then another 3 blocks. Then an electric engine. Suddenly your scope becomes much bigger. Then somebody makes mini LEGO to mask rough edges, making your creations almost realistic.

In other words, initially intelligent app builders will have very limited capabilities. As research advances, those capabilities will increase, in a snowball effect. At some point you'll be just talking to your phone and maybe touching screen here and there when making most web pages/apps, and all will be assembled from those building blocks. I believe we can now finally see a dimmed light at the end of the tunnel.


How is that different from say Unreal Engine, where you can already make a top-notch (graphics wise etc.) 3D game without any programming - by using their blueprint model? The point it, it still requires someone expressing the desired gameplay mechanics in terms of the blueprints ("lego blocks") -it's not that different from programming, except maybe looks more friendly than code.

It's a looong way from tools like that to a state where a CEO can ramble on his vision for some app in 100% natural language into the microphone, and clever AI figures out all the blanks and automatically programs it for him.


Yes, you are getting it ;-) So currently Unreal allows you pretty fast development using some blueprints. Now what is missing is some AI tool that understands a bit of context. Imagine you want to animate some character there. You can stand in front of a webcam and tell UE that the character should move like this, and perform the move. Then you review it, you see you really don't look nice on video, but the basics of movement are there. So you say "do it like this, but more artistic", and your AI will try to figure out what that does mean from some pre-trained "artistic" movements, and you can pick from the results; then you'd like to beautify it as you are out of shape and generally don't look like a model, so AI takes some pre-trained model info and launches a GAN to construct 3D body that looks like a "model" but follows your movements. Treat it as an advanced "pocket knife" that can automate some higher cognitive functions in the sense like "computer is a bicycle for our mind", and current AI allows you to do more complex tasks automatically. This will get better presumably, so each new iteration can do better than before.


I see your point now. I agree that, thanks to better tooling and libraries (some of those maybe based on AI), there'll be less reinventing the wheel, and so less jobs for non-awesome programmers. I think it has already happened in games, where, due to widespread adoption of engines, there's less need for experienced C++/maths/etc folks (and, thus, less room in the job market left for non-geniuses) and instead we see jobs for lower skill "engine operators" (ex. gameplay programmers in C# for Unity).

It has not happened yet in the general/business programming field thanks to:

1. Software and automation being applicable practically everywhere (and also in part thanks to bubble money) - the field is still growing at a mad rate.

2. Business problems being less conducive to algorithms and AI. For example, try coming up with a good AI which can figure out how to handle an edge case in a supply chain app. The AI would essentially need to understand humans.


Consumer demand is endless. The more they have, the more they want. Machine Learning, or whatever it turns into, will just expand the opportunities and the requirements.


...but also enable laymen to do many things all by themselves instead of hiring another person to do it for them. If done right, ML will increase power of everyone, if not done right, only of a few.

Currently the "art of programming" is a gift to a few. But if you look around you, almost everything people do is some sort of an algorithm, i.e. sequence of steps affected by inputs. ML will allow grasping some very difficult concepts which our brains can do naturally and help automate them, making those algorithms easier.


> If you really need to make software (like I do), make your own company and license/sell your work instead for >500% more than what would be your salary.

The hardest part about this (for me) is finding a project/product to begin working on.

I'm assuming you came to that sort of idea while working for others (which seems like the best way to learn).


If you do all the other recommended things, you'll start hanging out with people who spend money to solve real business problems. The projects will come to you then.


Would you say this is true even if you're not living in a tech hub like SF?


Yes. You'll meet different kinds of business owners, but they will have real problems.


I see - would you also agree that you will meet other people (such as other programmers/designers/etc) over time? I haven't met more than five at my current job.


IMO the hardest part is not finding the product, it is finding a person to handle the marketing/sales for you.


Most of the time I would assume there's always someone you can work with for this.

Finding other programmers or like minded people is the hardest part it seems for me.


For me, I can't do the front-end stuff, so I am stuck with not able to do anything with my ideas. This is where the networking part would help.


> For me, I can't do the front-end stuff

Why not? What's stopping you from learning?


I tried many times, I simply doesn't seem to be good at it.


I'm in a similar situation, but don't think of this as an unsolvable problem:

1. Find people who are great at it and be interested in how they do it. I think of this as learning to read good design before you write it. They may be interested in how you do what you do as well. 2. For me, one of the most productive steps was learning the basic mechanics of the bootstrap CSS framework. It did not make me better at designing beautiful web pages, but it did help me make something minimally usable (i.e. not repulsive) that lets me get my ideas roughed out. With a few days of learning, you may be surprised by what you can do. 3. If the best you can do is a cookie cutter design that lets you get started, congratulations! You can get started! What I mean is, I have felt what you are feeling, and there are ways around the problem. Good luck!


I really hope this has some elements of satire in it.


I wish... I worked for many companies everyone wanted to get in, and am still approached by big 4 ones G/FB/AP/AM (no MS as I rejected their offer already). What I observed is that consistently the ones that move to the top are the ones that master the practice of appearance, backstabbing, instigating fear of "missing the train" in superiors, throwing peers under the bus when fitting, betraying trust, sensing and adapting to prevailing winds, and most importantly making their superiors feel happy (I even experienced how a female colleague arranged a large deal with another company by having an affair with their VP, then got rewarded by becoming a head of a new office - I quit in disgust). It's Roman empire game all over again, software is no longer nerd/geek game (only if you wish to become a slave to psychos). If you still want to experience BS-free environment, move to bleeding edge AI/ML/robotics instead, that might have some 15 years future before it becomes another nightmare and all failed manager-types from other fields move in.


I have noticed there is a stark contrast between those who are aware of the political environment and those who aren't. You seem to be hyper aware and 'plugged in' to hear these stories. Most developers just write code and post memes on the team slack/hipchat channel, completely oblivious to things going on around them.

You should blog about some of this, changing names and obfuscating to "protect the innocent" so to speak. Also, read up on the Gervais Principal if you have not :)


Maybe it's that half of my family are politicians/lawyers, many of them leaning towards high-performing psychopathy and observing their behavior since being a child, their attempts to control me, expressing frustration I figured out their game and deny them, and then observing the same at work with those "ambitious persons", thinking anyone that does work is an idiot and should be handled like a child in a kindergarten, has something to do with me being hyperaware of what is going on around me.

Frankly, one of my favorite things in the office was to emit bubbles of incomplete information to individual persons and observe who gets to know that piece of information, mapping alliances at work - they were oblivious of being tested, always triumphant they knew better and it was just fun to simulate a clueless person on my side just to understand how did they exactly operate. Try it, it's fun and a quite harmless "game people play".


That second paragraph makes it sound like you picked up some of those psychopathic tendencies. It doesn't seem healthy to play those types of games with people, as harmless as it may be.

Yes, the reality of life is that it's not a meritocracy or even within a stone's throw of it. There's a fine line between acknowledging the reality of it and succumbing to it. The abyss gazes also.


The comments you wrote in this thread really hit me. I truly appreciate your writing them down, and as other posters have said, writing a blog post about this would be really helpful to us. What you're saying is true. No one cares about the tech.


The Socratic method, isn't it?


Those "most developers" make it to Senior, and then stay there until they leave the company. I was at MS for 6 years, and can confirm much of what the GP said. Some people succeeded on merit, of course! But mostly any real success was extremely proportional to your skill at Machiavellian intrigue, and willingness to engage in it continually. That was surely the main game. Every org change or VP change was surrounded by a lot of Game of Thrones.


Exactly. I've also been burned out from an highly political environment, seeing how people raise to the top by basically following advice of the kind given in '48 laws of power'.

But in a way it's been eye-opening, seeing this darwinian play go on, it confirms a lot of my theoretical understanding of evolutionary psychology, I find it quite fascinating. Not only that, but just observing it shows you how to improve in this area.

But from what I've observed, most people are completely unaware of this side of things. A certain personality seems to be affected by this "issue", and that personality seems to correlate quite highly with caring deeply about their work, pursuing excellence in their field and so on. But alas, no-one has written more clearly on the topic/ psychology of corporate politics than Michal O. Church, I do recommend reading his essays for those affected by the issue (even though he has acquired a bad reputation around these places, probably because this is a sensitive issue).


So you've never worked at those companies, and you are assuming what it's like to work there? And are you claiming you make 500% more than say a senior engineer at G/FB?Am?


I actually worked for better companies (with emotional attachment from developers), one top-end pioneering company that invited all developers at least once a year to Silicon Valley regardless of rank, and one in particular that refused G's acquisition multiple times and G was forced to make an alliance with it, and this company is loved by many at HN these days. Ranked higher on Glassdoor than G/FB, and more than 50% of departures to G returned back within a year, telling all of us it's not worth it. Also having friends at G expressing their jealousy at what I was working on that they could only dream about at G. Which is why I am targeted by those big 4 companies all the time, and couldn't care less.


Hah, so will you tell us the company? Sounds like some of us should be applying there... (though it did seem to make you not want to stay and be a developer there?)


You all should ;-) But I believe in independence and my inner motivation is that no company utilized my potential to more than 10% even if I was working on their most difficult problems and created things that got to #1 spot on HN no one has created before (and boredom sets in). Even G tried to motivate me by telling me they are now having "the most complex piece of software ever built" and I have a chance to work on it. Will talk to FB again shortly, will see what they want this time, but as I said, I don't really care.


Nope. It's not far from the truth.


Well, if it does, I can copy and paste it here under my name without the satire.


This is the truth if you are locked into only working at fortune 500 companies (ie. large enterprise shops). Once you branch out from those to small/mid-sized companies you find a lot more variation and not so much stupidity. I find mid-sized companies tend to be the sweet spot between minimizing stupid politic and receiving decent pay.


Just wanted to add that bitL vision is the actual truth even if the cynical aspect has been singled out. What bitL describes is the single most important factor in career advancement for a lot of software companies I've seen.


This is a great post. Read it and do the opposite of everything it says.


>There is no future in software development as a job. this


I knew you were joking when you said our field used to be a meritocracy.


You're going to read your code 100x more than you're going to write it. Optimize the code you write for reading.

Your code will be in production either much longer or much shorter than you think it will. The 5 lines of code you spend three days perfecting will be replaced in a week, and that one-line 3am hack will be out there for ten years.

A good walk around the block will help you solve a problem faster than staring at code.

Find someone smarter than you and learn from them. The corollary is if you're the smartest person in your area, you're more likely to stop learning.

What the customer needs is rarely what they say they want.

You will derive more long-term benefit from finding an answer yourself than finding that answer on Stack Overflow, at the cost of time. When time matters, at least try and understand why the Stack Overflow answer is right.

Don't be afraid to question a decision you don't understand, or don't like. At best, you'll get either your mind or the decision changed. At worst, you will learn something about your co-workers.

There's never enough money, time, or domain specific knowledge.

Office politics matter, regardless of how much you wish they didn't.


> Find someone smarter than you and learn from them. The corollary is if you're the smartest person in your area, you're more likely to stop learning.

Maybe. I think the other side is find someone smarter than you, but less experienced, and teach them.

You learn much more from teaching than being taught.

If you're at loss of finding smart adults, find some children ; they're probably all smarter than you, in the sense of finding good questions (which is much more interesting than finding good answers; finding answers is just work, finding great questions require inspiration. A perfectly good example of a good question is: "why is the sky blue?").


If you can't find someone to teach you, then yeah, this would be a good alternative. And so long as you're willing to put significant effort into correctly answering their questions, it should be a good substitute.

That said, teaching will not typically help you learn something new, though it will help refine the knowledge you already have.

For example, answering "Why is the sky blue" will give the chance to refine your own understanding of refraction and how that interacts with air, but it's unlikely to guide you into learning about quantum mechanics.


> unlikely to guide you into learning about quantum mechanics

True, but that depends on assuming the person teaching is really only interested/aware of an answer that deals with refraction, and that the median mental model most people have isn't close to understanding the mechanics of refraction. I've noticed that the levels of abstractions we employ are all affected by these sorts of questions, perhaps the same question a year later would afford one the chance to unravel a particular layer assuming the layers above it are sufficiently saturated in understanding :D


> Find someone smarter than you and learn from them. The corollary is if you're the smartest person in your area, you're more likely to stop learning.

The issue I have with this is finding that person.


There have been some posts on HN about hiring more experienced developers for one-on-one tutoring / pair coding over Skype (on freelance websites etc).

A guy wrote a blog post about it (can't remember name), he hired a couple people for a half hour each until he found one he liked.

Alternatively see if there are any meetups in your area (meetup.com is great for that).


> A good walk around the block will help you solve a problem faster than staring at code.

This has really helped me out with some nasty bugs.


>You will derive more long-term benefit from finding an answer yourself than finding that answer on Stack Overflow, at the cost of time. When time matters, at least try and understand why the Stack Overflow answer is right.

Absolutely agree! You have no idea how much I have learn from reading the official documentation of whatever tool I am using vs a basic stackoverflow answer with little explanation.


> What the customer needs is rarely what they say they want.

I'd like to extend this to include designers, non-technical cofounders, and non-technical colleagues.

I had a situation just recently where I built out a new front end interface for a new feature I had just built. There was a particular work flow that I had carefully laid out for a specific task that involved rearranging items in a list. Not having a 100% explicit spec, I was free to improvise within constraints.

So, I built this interface out and tested it.I then handed it over to my colleague who is responsible for green lighting new features and such. Well, my colleague decided that the interface should be completely rebuilt for better usability. That's fine. No problem, that's my job. Though, it would have been nice to have a spec up front so I don't have to throw away hours of work.

So, I convince my colleague to write out a very detailed user story so I can make the interface just how they want it. I get the user story and I completely rebuild the interface. I then hand it over to the same colleague and they say that the interface still needs improvement. I'm confused at this point because I followed the spec to the tee. They explain how they want to improve the interface and their explanation sounds almost exactly like what I had implemented the first time! Needless to say, I was a bit ticked off. That said, it's best not to make a big deal out of it as I am getting paid for my work and I don't want to make my colleague defensive.

Luckily, I had the old version in version control on another branch so I was able to pull it back into the working branch and make some minor tweaks.

Moral of the story: Non-technical people don't really know how to express what they want to a technical professional. I'm in no way implying that non-technical people are inferior. They just don't understand the job of a technical person and all of it's implementation details. The same issue applies to fields other than software development. For instance, it's difficult to express how you want a contractor to build something if you have no experience building something.

You will also run into people that have no idea how to do your job and have no idea how to express what they want, but also insist that your job is easy. These people are idiots. You just have to humor them until they inevitably fail at their own jobs and go away.


> You're going to read your code 100x more than you're going to write it. Optimize the code you write for reading.

A bit of a tangent here, but this is why I could never bring myself to use Scala. At least early on, their pitch for the language was frequently backed by code comparisons where many lines of relatively verbose Java would collapse neatly into just a few lines of Scala.

For me, at least, I had the realization that even if I figured out exactly how a particular block worked, revisiting it later would be a huge challenge in terms of re-learning. Java has proven itself to be a lot more readable and self-explanatory.


> Your code will be in production either much longer or much shorter than you think it will. The 5 lines of code you spend three days perfecting will be replaced in a week, and that one-line 3am hack will be out there for ten years.

On that note, I was surprised to see this comment when looking through the source code of the now-venerable program traceroute -

"Don't use this as a coding example. I was trying to find a routing problem and this code sort-of popped out after 48 hours without sleep. I was amazed it ever compiled, much less ran. [...] Van Jacobson (van@ee.lbl.gov) Tue Dec 20 03:50:13 PST 1988"


If I could go back in time and give myself advice it would be:

0) Nothing is too hard to do, no matter how much those doing it might seem like towering titans many levels above you, or how out of your reach it may seem. Nothing is too hard, there are only things that take time, and things that take more time. If you put in the work, those titans will be your peers before you realise it. Of course, you can't do everything. If you want to put in the amount of work needed for some things, you need to focus. That means deciding to not do some things that you want to do.

1) No-one who is serious about programming gives a shit about language wars, they're for fanboys and spectators. People who get shit done are too busy to spend time on that. So don't sweat what language you choose (too much – there is still such a thing as the right/wrong tool for the job) and especially don't worry about the people insulting it.

2) If it's not constructive practice, you're wasting your time. I spent too much time - literally years - spinning my wheels, writing code but not getting any better at it. Make sure you're reflecting, make sure you're improving.

3) (related to #1) seriously stop worrying about choices and just get something done. You don't get things completed by worrying if you're using the right language/framework/library.

Unfortunately I worry that this advice would send me down another bad path and I'd probably need to add on something like:

4) All that said, some languages really are limiting, either in what you can do, the level of concepts you will learn, or straight up teaching you bad habits. Likewise some libraries / tools / frameworks are actually bad. While you should definitely avoid trying to optimise the last % of productivity, you should spend some time to make sure you're not using something highly suboptimal. If after reflection you believe you are using such a language/framework/etc, then broaden your horizons. That doesn't necessarily mean rewriting your current project, maybe do a toy project or some exercises in something else.


Regarding 2, how do you suggest I avoid "spinning my wheels and learning nothing"? Over the last 6 months I've becoming increasingly aware of this problem with me, but I don't know how to fix it.


Whenever you set out to write something, write it differently than last time you did it. It takes conscious effort and a lot of getting used to but actually stopping and thinking about alternative ways of doing something is a practice in itself. When you act on these thoughts, you're most definitely practicing, and quite probably improving.

This approach scales from the tiniest pieces of code to whole systems. If your last loop was a simple `for` loop, try writing the next one as a call to map function. If your last loop was implemented as map, write a simple `while` the next time. If your last app used Postgres for persistence, use Redis or CouchDB for your next one. If you're comfortable with MVC, use MVVM for your next project. If you're fine with dynamic typing, try using statically typed language or dialect.

Seriously - do it. Nobody is going to say anything to you: they all do the same to stay relevant, even if they know it's not the best strategy for a team as a whole. Make it your policy not to repeat yourself and only fall back to the tried-and-true ways of doing things if there are external circumstances which put you under some great pressure.

After a couple of years of this, you'll accumulate most of the techniques and skills you could ever need. The techniques and skills I talk about are transferrable between tech stacks to a certain degree, are impossible to learn/master quickly (no matter how intelligent you are the amount of information is simply too great) and really matter in practice. That knowledge is what differentiates senior programmers from others.

Anyway, good luck!


I don't know about doing this in a project you're being paid for, it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place.

Four years in I'm hoping the OP has seen a pretty broad range of different styles and approaches and is now ready to hone their craft with smaller improvements, and is no longer struggling just to get something working so they now have some extra energy to put towards maintainability and overall system design.

It might be better to try to define and refine a consistent style that can be applied to an entire project, that way you have to evaluate all the options, and do everything intentionally, but also you're not sending the next dev back to the syntax manual every time they try to read a new function.


> it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place.

But simple things are being done differently anyway, all the time. There's too much variation in how you can code anything. The most trivial functions, like leftPad, can have dozens of implementations across a couple of projects - each as correct as the others, some abstracted, some inlined. Above a certain proficiency level, programmers are expected to intelligently recognize leftPad when they see it, even if it's called `frobnicate` and is implemented backwards (whatever that would look like). How can you expect programmers to do this without them going through a large set of sample implementations? Are they going to wake up some day to realize they got enlightened and now have no problems with dealing with leftPad in any of its many forms?

I find the argument of "increased cognitive load" entirely unconvincing. Yes, the code should be optimized for reading. But, as every writer knows, how you write depends on who are you addressing. In other words, it's both insulting and counterproductive to write your code as if your readers are bird-brains with severely damaged hippocampus. Your readers are professional programmers who know their craft - possibly better than you do - so have a little faith in them!


You might like this piece of John Carmack's advice: If you're not sure which way is better, implement it both ways and compare.


Consider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.


There's some really great advice here from others. I'll add what I personally needed to learn:

I got comfortable with the small subset of the language I knew, and then used those tools to try to tackle all problems. I eschewed some of the more powerful abstractions because they seemed complicated and unnecessary, and because learning them would take me longer than forging ahead with the tools I already knew.

What I didn't realise, and seems obvious in hindsight, was the time to learn those new tools was an investment. If I knew them, I would not only be able to tackle problems faster than I could with my current tools, I would also be able to tackle far larger problems than were feasible to do with such basic toolset.

I think a possible rule of thumb for when you are being limited in such a way is when you're hitting a ceiling - when there's a complexity point you can reach, but no matter what you do you can't seem to push past it to make bigger/better things, it's time to "level up".

Another possible rule of thumb is if there's some framework or library or technique that others seem to be using and you look at it and think "but that's way more complicated than how I'm doing it!". Maybe it isn't unnecessarily complicated, maybe that extra complexity is the "cover charge" for being able to create larger and more powerful software. (An example: using an MVC framework rather than a bunch of pages with in-line database queries and templating.)


I imagine that there are things you know about that you don't fully understand or haven't put into practice yet. So focus on understanding them, and especially understanding them by doing them.

And if by some miracle you don't have enough of those things, spend more time on HN ;)

Edit: Getting a mentor can be tremendously helpful. If you work at a company see if there's anyone you can get paired with. Someone more experienced is great, but even someone at your level is likely to know some tricks you haven't learned yet.

Alternatively, ask a friend, go to meetups, or you can even hire people online to teach you how to code (on freelance sites etc).


In addition to what others said, make sure you realize when you're learning or not. If it's painful to do something, you're learning. If it's easy going, you're not learning.

More here: https://codewithoutrules.com/2017/04/17/learning-without-a-m...


If you are writing software, learn design patterns and create some example application using them to really understand where they fit. Doesn't really matter what language - object oriented one would obviously work best. There are also books on architecture and integration patterns.

For everything in your tech stack - find out the sweet spot use cases and the ones where really you should use something else. For example with databases - don't repeat your data (aka normalization) is common - when does that not apply?

Spinning your wheels would be things like trying new languages, frameworks, etc. for the sake of just trying them out. It's like going to a car dealer and test driving without any real need or intent to purchase - literally spinning wheels :) You might be fooling your brain that it is learning when you are really just trying something new that is nearly the same as something you already know.


Take on bigger technical challenges and keep a notebook for writing down new concepts you learn along the way. Of course the notebook could also be in software. But write. It'll help you internalize stuff.



5 things:

1. That statistics and metrics collection is incredibly important even if you only ever use it via libraries.

2. That code performance doesn't matter if the code is incorrect or insecure. So much of my life in industry has been tainted with an influence to conform to the cultural norm of "fast is best." This influence and culture is one of the most counterproductive parts of our industry.

3. The industry is actually full of great people, but those people avoid most of the media hubs that projects have access to because a tiny slice of terrible people dominate discourse. These assholes set the tone for the entire industry, and should be ostracized and punished. It's not everyone, it's a thin coating of hate.

4. Corollary to 2 and 3, I wish I learned to ask for help earlier in my career. I wish I could go back to my younger self and take the chip I'd acquired working with government contractors.

5. Corollary to 4, I wish I realized that I should be reading academic papers and that the people writing them weren't wasting time. Much of what's considered modern state of the art is in fact 5-10 year old work out of universities and MSR.


13 years.

0) Money. the big money is in projects that need help. E.g. CEO during your interview: "The last lead programmer flipped me off and our accounting system in small talk is broken." That's hard. But that is where money is.

2) errors happen. Do tdd - so you can go to that concert.

2) Be the go to guy. If someone needs something you better be able to help. Brushing someone off creates office enemies and will remove any hopes of promotion.

3) any idiot can write code. I can with one hand tell you the names of people that can take over a system with 500k of mangled code.

4) think win/win. If you are doing a project - work hard -win for the company, but also put it docker so you learn something too.

5) launch side projects. You should release something large every year.


I really like this response because it is helpful and practical but not overwhelmingly cynical or Machiavellian. You can do well by doing right in this field!

I think a corollary to 0 is that if an organization is in trouble it will usually find a way to always be in trouble. It's human nature to think a crisis is always almost over, often it's only beginning.

For sure, taking over a troubled project is a great and honest way to make money, and I love sorting out tangled messes where the original developers have all left (hit me up if you've got one, email in profile!), but just make sure that the problem wasn't a chaotic or toxic work environment.

People and their interactions are more important than events and circumstances in terms of creating an environment. Some teams run on crisis and others run on collegiality. The direct and indirect benefits of a positive work environment are tremendous.


If you're self taught, get a degree as soon as you can, even if you take night classes over an extended period. No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

If you're not a founder, NEVER take equity in leu of salary. If they offer a competitive salary and equity, that's a significant plus, but equity as a portion of your compensation value is essentially a scam. if the company goes under or you're let go before the cliff (which is usually two years or more, a lifetime in this industry), all that money disappears: not true of salary. If a founder or officer alludes to houses, cars or other riches as a pitch to join their company run. Seriously.

Take the time to understand systems and infrastructure. Not every dev needs to be a kubernetes expert, but the big difference between a code monkey and a code assassin is that the assassin can deploy their own code to production if necessary. If you're a web dev and you can't configure nginx or apache, you have a gaping hole in your skillset.

Launching off the last point: learn to be competent with linux. Linux is the preeminent environment of the software world and it pays huge career dividends to be able to script, configure, compile, install and maintain linux software and systems.

RTFM. This is a big one. Don't skim. Relax and dedicate some time to a thorough understanding of details. You can save yourself an immense amount of time when working with a new library/framework/language if you actually read the manuals and understand what your tools are capable of, otherwise, you end up wasting tons of time brute forcing your way into a crude solution that may have been trivially and correctly solved by utilizing the tool's strengths and features where appropriate.


I'm self taught and will never get a degree, unless it's for fun and completely unrelated to CS. The recruiters at those companies skipping me over are just doing a part of my job for me - filtering out places with culture that I wouldn't want to work at.


> If you're self taught, get a degree as soon as you can, even if you take night classes over an extended period. No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

Not true. I'm self taught and I had very generous offers from the two of the three big names.

Screw spending a time to getting a degree just for the sake of it and build stuff.

I know it wasn't like that before, but times have changed and so have recruiters.


I don't mean to suggest that you can't get great opportunities while self-taught, only that a sizable portion of opportunities will be closed off without a degree. There happens to be a glut of developer work at this time, so the consequences are dampened, but that won't be the case forever, better to get the degree when you don't need it rather than wait till the time when it makes a bigger difference. Also, I'll add that getting hired by an elite software firm is absolutely possible without a degree, but you have to be considerably above average intelligence and skill to get in the door, whereas a degree will give you an opportunity to get in the door even if you're not a star, providing you with the environment and resources to become one.


> No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

If the company looks that closely to academic degrees, it most probably doesn't know how to hire staff. I don't want to be the only competent person around.

> ([...] two years or more, a lifetime in this industry)

Where "this industry" is "startups plus websites". General IT doesn't move that fast, especially with regard to good tools and ideas. A carefully chosen toolbelt of things that are ten-fifteen-twenty years old is still stronger and more flexible than most of the new sexy applications programmers now use.


> Where "this industry" is "startups plus websites".

Well yeah, only in the startup world are software developers offered equity instead of liquid compensation.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: