* Always be solving problems
* Make mistakes, and learn from them
* Just because something didn't work 5 years ago doesnt mean it wont today
* Don't buy into hype
* Be passionate and excited about things. You're not a robot
* Don't feel guilty about wasting time.
* Don't overabstract every problem
* The quickest solution is generally the best solution -- or at least help you understand the problem better. Don't design a large solution to a problem, solve lots of smaller problems.
* Do things that align with your strengths
* Know what your strengths are
* Build relationships with people. Be their friends. Talk to them about non- work related things
* Keep meetings to 30 minutes. Always have a takeaway from a meeting
* Have a life outside of work
* Set goals for yourself. Set goals higher than you think you can achieve. Make a plan for achieving the goal.
* Hold yourself accountable
* Don't be an ass
Making friends and socialising is not something that comes easily to me so this is something I have been actively working on for the last year and it has had a profoundly positive effect on my work-life.
I am still amazed at how much more willing people are to go out of their way to help me work-wise when we have even a small(?) personal relationship.
* there's always something to learn. You know that, but you'll lose sight of it.
* look at the bigger picture, always
* don't be afraid to ask questions, as many as you need until you have the information you need.
* worry less about what you want, and more about doing the right thing for the customers you're building for. (In the end, there's a surprising amount of overlap...)
* 12 hour days might feel good, but they don't help in the longer term.
* you can't do it all yourself.
* you'll get paid more than you need to survive - so don't be an idiot with your money.
* talk to people. continue to talk to them after you are no longer required to interact with them regularly. Relationships are work, but they're important to your sanity and career.
* Those things you avoid because they're too hard? They're not really too hard, and that's not really what's stopping you. There's nothing wrong with failing.
* Those ideas you have? Do something with them. But one at a time, and make an active choice as to whether it's worth finishing.
* There will always be things that you want to do better. Don't let that stop you from shipping.
* Don't read comments. And for the love of FSM, don't reply to them.
> you'll get paid more than you need to survive - so don't be an idiot with your money.
Adding to this is something to consider:
You will be paid more than you need to survive, but you will most likely survive longer than you will be paid. Make sure you save money for those times.
That knowledge will build up with time, and someday, a younger developer will come to you with questions. Take the time and answer them; it's worth it.
* Switch employers every 2 years. Do not have loyalty unless you have stock options.
* Contribute to open source for the learning experience
* Use what works, dont focus on the hot new trends (redis, mysql, django, ror vs express, mongodb, etc.).
* learn at least one functional language really well
* learn one statically typed language really well
* learn one dynamically typed language really well
* multiply all time estimates by some coefficient C, where C is always larger than 1.
* become familiar design patterns described in Gang of Four
* learn the UNIX commands and piping really well, they will save you a lot of time.
* have side projects and dont be scared to show them off!
You consider mysql, django, and ror as "hot new trends"? What databases systems and web frameworks do you consider not to be "hot new trends"?
I first used mysql 15 years ago, and it was already an established project at that point.
2. Always test your code, and if you're writing in language you're new with get someone else to code review it. Especially if you're bugs are likely to break your company's main customer.
3. Technology is worthless if it doesn't help you achieve your goals. Software is worthless if it doesn't help you achieve your goals. Figure out your goals first.
4. Put another way, ask "why", don't just code.
(These are all based on actual mistakes I've made. You can get the full story of these and other mistakes I've made at https://softwareclown.com).
- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
I'm sure that Rob is a great employee, and the book does have a few good points, but I'm not sure I took away a whole lot from it.
It's funny because technically, none of these three things are part of an engineer's job.
But once you do them, you start noticing how you eventually get to: - save yourself time - save your customer money - avoid unnecessary complications down the road - offer useful comments / feedback / critiques / alternatives, when need be (because you better understand the decisions made around you) - help your customer or team better understand what they really want - find yourself in a better position to transition to other roles, if you choose to
Btw, I wrote a blog article a few days ago about exactly this: http://claudiu.dragulin.com/2016/12/02/dont-just-code-solve-...
- don't spend to much time on exploring tools, but whenever you notice you're repeating yourself often, make sure to do a quick search to see if there's a quicker way. There usually is, because others will repeat themselves in similar ways.
- make sure to find real projects (where you get paid or at least dinged for not delivering) that offer a degree of challenge/unfamiliarity. I've gone months with very little progress in my abilities, only to take on a project with an unfamiliar toolset or environment and learn a shit-ton of stuff that helped my long-term.
- find a mentor!
- look into this 'functional programming' thing, but don't become a convert. It's not the solution to everything.
- if the coding you do for work doesn't excite you, make sure to find some exciting side-project. Programming, at least for me, is so much fun. I've let work take the fun out more than once, to the point where I'm seriously considering finding some other line of work to make a living so I can code just for fun. 'Unfortunately' my front-end work is so lucrative that it's the best way to have as much free time as possible.
And the two biggest ones:
- "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." and "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I can't properly express how much this has improved my coding. I don't think it's a coincidence that React/Redux (often) put such an emphasis on one big state object to work with. If I start my work with thinking about the data structures and their relationship, the code becomes so much easier to write!
- Watch 'Simple Made Easy'.
- Always judge the business value of any change request
- Be weary of any technology that promises to revolutionise the world of programming
- Get to know the whole stack, even if only in abstract terms, don't focus on silos
- Care about the business side, how the technology meets the needs of the actual users and way of doing business
- Never ever sacrifice private life for the employer. They won't think a second about your sacrifices when showing the door to teams
The goal should be continual improvement which includes successes and mistakes. Preferably, these are done at a pace that lets you enjoy your youth, family, friends, and life.
I often find that mistakes other make are valuable for me to learn from as well. I could make every one of these mistakes serially as well, but in some cases, learning from those of others is a good enough lesson for me.
* always be learning, but focus on architecture and design, not implementation specifics
* work hard, but make sure you don't forget to live
* always do a good job, never burn any bridges, and in 10 years things will be great
Also, be open to tasks that are not just hands-on coding. Tasks related to testing, documentation, mentoring, product management, project management, etc. add value to the business and make you a more valuable and versatile player.
And by that I mean be involved in projects from start to finish.
If you find yourself at a company for more than 2 years, and you've only worked on 1 boring project, it's time to look for new opportunities. Now, there could be multiple small projects as part of one big one, that's different, as long as it provides you value and helps you progress in your career.
The only way to progress as a software engineer and get a solid understanding of the SDLC[0] is to keep cranking out projects from start to finish.
There are far too many people that get stuck maintaining a project right out of college, and never experience the full SDLC.
The more projects you deliver from scratch, the better you'll be at estimating tasks, understanding risk, business priorities, etc...
[0] https://en.wikipedia.org/wiki/Systems_development_life_cycle
keep on learning and make use of what you learned, and don't be afraid to be less than perfect and make mistakes.
* Remember that people with non-software skills are probably just as smart and hardworking as you are
* No matter how much more qualified you are than your coworkers, don't fight every battle even if they are always wrong
* Actually read (don't skim) documentation and source code
* After you have some money saved up, quit your job and look for your dream job full-time
* You'll be perfectly happy having never worked in Silicon Valley, or for any prestigious companies
* Read error messages and understand instead of just googling
* Switch mentors often
* Forget about getting rich
And maybe/probably smarter.
One of the smartest people I ever worked with was a sales guy (gasp). The dude could spend 3 minutes listening to you explain something, instantly grasp the problem, have an idea of what the solution would look like, then communicate that to the customer in a way that made it look like we were doing them a huge favor. He had a non-technical degree and his background before joining our company was at a car dealership.
He once declared himself Master Lord Architect of All Things Technical after he figured out an issue to a problem in the span of a conversation that took three engineers the better part of a week.
I did not object.
Please watch this video. I don't agree 100% but with most of it: https://www.youtube.com/watch?v=QM1iUe6IofM
The new Object Oriented WP 6.0 macro language was unable to do the things I did with the 5.1 macro language (a typewriter mode for diacritics plus spell checker plus smart commas and smart spaces).
Since then, I have always been an skeptic about OOP.
Also: closures are not too different to instantiated objects, one can usually convert from one style to the other while keeping all functionality.
* Think in the problem space / avoid thinking in implementation details. Structure your solution along lines that make sense in the problem space, name variables for that, etc.
* Do the simplest thing that solves the problem at hand, but no simpler. Small, simple implementations are easier to change when (not if, when) unanticipated changes come up. If you anticipate additional functionality, leave the door open to those changes rather than writing code for them now.
2. Your manager can make or break your career. If you have a bad manager, you need to get out or you will always be disappointed when it's time for promotions and raises.
3. Soft skills matter way more than the hard ones. You don't have to be a good public speaker, but you need to know how to navigate difficult situations.
On the other hand, if you have a good situation (realistic management, decent pay, good co-workers), think very carefully before moving. Such situations are not all that common.
* Study new things 8 hours per week
* You are not the R&D department for the next cool thing, use established tech to build your own cutting edge product.
* Take stock in lieu of salary and go all-in
* Focus on reduced cycle time for development; e.g., develop against small representative datasets
* Learn new programming languages regularly; i.e., don't be a C# expert without also knowing python, R, scala, perl, Go, etc..
* Relationships are very important, learn to be social, it isn't always easy
* Learn to ask questions rather than make statements with your team members
* Never make things personal or question people into a corner, the goal is larger than the current issue
* Long-term employment in technology isn't. You really need to try out new companies from time to time and challenge yourself.
* Be a servant leader to everyone around you.
* Mind dependencies, resolving constraints gives you immediate freedom and accelerates progress
ps: great thread.
* Admit when you don't know something and then rectify it (if it's interesting to you).
* A stable solution is better than the bleeding-edge solution.
* Smaller (simpler) is better. (KISS)
* Learn how to gauge technical ability in a conversation with someone and compensate for that on the fly. Non-techies will love you.
* 80hr weeks will not make the company love you. They will only make everyone else in your life dislike you. And eventually, the people at the company.
* Shop around. You don't have to take the job offers but keep interviewing. You learn as much about yourself as they learn about you.
* Find a problem-space you love and develop it. Tech is tech but business is business. Finding an area that you like to solve tech problems in will make you happy.
* Don't make technical arguments personal. Make your point, with facts, let them make theirs. Agree if you're wrong.
* Don't waste time & energy learning trendy tech. Hold your excitement and ask yourself: "what can I do with it that I can't do with my existing arsenal and is it worth the ROI?"
* Learn to identify companies that are nothing more than feature factories
* Ownership is better than a paycheque. It means control over your decisions and work quality.
* When working at corp/consulting, focus on the things you can control and the people you can influence. The rest is out of your hands and not worth the emotional investment.
* Learn to let go. Tech gets out of date. Software you spent years working on gets replaced. Stuff stops working because of dependencies down the line. Nothing lasts forever.
* Focus on getting better and investing in yourself.
Know programming patterns. Be able to categorize a problem as an instance of a pattern (or not).
Know what you don't know.
Execute.
Being better at debugging is more valuable than coding faster.
Train those junior to you as if you want them to replace you.
Use the Socratic method. Ask a lot of questions. Over-communicate.
Be able to adapt yourself to the person you're talking to.
Be able to manage "up." People should trust you not only because you can get things done, but also because they are well informed that things are getting done the way they want.
The main advice I give to junior developers is that state is the core of incidental complexity. Focusing on minimizing state to the degree practical is the simplest trick I know for producing well designed systems. The only place it doesn't necessarily work is high performance code.
I cringe when developers call for a rewrite. It's a massive red flag to me that they aren't team players and will be lazy. They won't take the time to read or understand things. Rewrite calls make more sense after they have read the code in the first place to being with.
* Work hard and earn/learn as much as you can in the first 10 years of job. Volunteer for code reviews, take up jobs outside your comfort zone, build a solid network of peers. IMO, what is learnt in the first 10 years is gonna stick with you for the rest of your career, so be a sponge and absorb as much as you can in this time !
* take risks, work for a company that wants to change the world
* contribute to open source
* code is read more than it is written, learn to write code that is easy to grok
- Stop underestimating problems, assume they are hard until you can prove they are easy.
- The squeaky wheel gets the oil. Doing great work that no one knows about doesn't get you recognized, and doesn't help anyone.
- Trust your own intuition and insight more. They are often correct about other people and your own life direction, but get ignored too often.
* Don't fall for the line, "We'll fix it later." It will never be "later," and the problems will never be fixed. Do it now, while it's cheaper.
I would gladly have traded off some of my career success for more family time...had I known then what I know now.
I took some risks and enjoyed my 20s and early 30s immensely, but also played it pretty safe. I would advise my younger self to take more risks, specifically around creating products.
* People are more important than code
* Don't fall in love with specific technology
* Do not rush, force yourself to slow down
"do you want to work long hours sitting at a computer everyday until you're dead?"
They hate you because you have skills and they usually failed in their careers (or have a liberal arts degree, which is even worse).
They will record and make public whatever you told in private.
They will blanket spam your CV to every corner of the world.
They will lie to you to make you sign it.
They will make you feel worthless so you can accept a lower package.
http://www.theatlantic.com/business/archive/2012/04/53-of-re...
The problem is not intrinsically the content of the degrees but the fact that there is probably 2x as much graduates being thrown in the market than there are jobs.