Recommended
More Related Content
What's hot
What's hot (20)
Similar to Stuff I wish someone told me about being an engineer
Similar to Stuff I wish someone told me about being an engineer (20)
Recently uploaded
Recently uploaded (20)
Stuff I wish someone told me about being an engineer
- 1. Stuff I wish someone told me about being an engineer Jeffrey Walter Senior Computer Scientist Adobe
- 2. Titles are b******t. • Do not hang your identity on your title • They mean a lot to some people
- 3. Process Matters • Don’t be a cowboy • Find a process that works for you • Follow that process
- 4. Ask for help • No one expects you to know all the things
- 5. Google is the best
- 6. They’re gonna find me out! • Imposter syndrome never goes away • It does get better. I promise.
- 7. You are not hot s*** • The all knowing neck-beard is not amused • You can be that neck-beard
- 8. Making mistakes is not a requirement • Pair programming • Code reviews • Open source
- 9. It’s easy, right? All you have to do is… • NO! • What is the problem are you trying to solve?
- 10. Problem solving • Syntax is gravy • Whiteboard, pseudo-code, rubber duck, toy problems
- 11. Constantly self evaluate • Stuck in a rut
- 12. PRIORITY ALPHA 1!!!! • Not everything can be priority 1 • Keep a task list
- 13. Technical debt • Never prioritized • Do it anyway
- 14. Past you is an idiot. • Ten minutes ago you is an idiot • 1 month ago you is a crazy person
- 15. Sacred cows are tasty • Rip it out!
- 16. Estimation sucks. You suck. • Dunning-Kruger effect • Better stories == better estimation
- 17. Passion • Lies!
- 18. The Hard Stuff
- 19. • Follow Sandi Metz’s rules • Test all the things • DO NOT USE EXCEPTIONS FOR FLOW CONTROL • Learn how to debug
- 20. CS fundamentals • Write a linked list • Write a binary search • Memory structures • Pass by reference vs pass by value • Garbage collection • SQL • Write a recursive tree traversal
- 21. Programming Patterns • DRY • Bike Shedding • SOLID • Dependency Injection • Map/reduce • Memoization • Null object • Functional Programming
- 22. Architectural Patterns • SOA • Microservices • Load balancing • High Availability • Pub/Sub/Observer
- 23. Stuff you think you know already • Interviewing sucks • The little stuff matters • Stupid people exist • Peter principal • Office Space • It’s ok to work for Innotech
- 24. Don’t be an asshole • Tag, you’re it! • Misogyny/Racism/*ism is real
- 25. Thanks! • Lehi Developers User Group • Email: jwalter@adobe.com • Twitter: @jwalter748 • Slack: LDUG.slack.com
Editor's Notes
- In no particular order And a whole bunch of em
- Like fightclub, you are not your job Be aware that titles
- Everyone hates cowboy coders Use the process at work, look for ways of doing things. Scrum, GTD, kanban, tdd, etc It’s when you break your process that you find you encounter problems
- Don’t wait 2 months into a project to ask for help.The longer you wait, the less likely you’ll ask for help until it’s too late.
- Everyone looks stuff up. The most surprising thing to new engineers is how much I look up things on stackoverflow I ALWAYS have the ruby api open.
- it’s one of those things every engineer (unless you are a psychopath) always thinks. Serioulsy, it does. You get confidence. But try not so sweat it. People understand where you are at. And in most cases, people will be impressed by your abilities, not dissappointed On the flip side
- Fear the neckbeard Just wait. It’s fun
- There is a common trope that you have to make mistakes in programming to really learn something. Not true. There are a lot of resources for you to build knowledge without making the same mistakes I did
- Remember these words. Despise these words. Product manages love these words. Your job is to say NO!. In some form or other This is your response You are the programmer…you know best how to solve a problem.
- 1. I don’t care how much syntax you know. (See earlier slide about google) 2. Hone these skills to learn how to solve problems
- 1. I spent a long time in my career doing what I hate, because I didn’t review myself. Career/skills/process Read blogs, learn new things. Talk to people
- The world is not gonna end. I promise Seriously. If this is priorty 1, what about the 27 other priority 1 tasks? Counter this by keeping a prioritized task list. When someone tells you to do something. Say “Sure, just tell me where it falls in this list of priorities” If your jobs uses JIRA/Pivotal. Great. Add your tasks. If you can’t account for all the things you do, at review, your boss is gonna ask “What did you do?”
- So you want to refactor the distribution engine? You want to move your HAML to ERB? No product owner is going to prioritize your technical debt Do it anway
- Click Click That feeling you get when you review your old code never goes away. Head scratching and face palms never stop. Don’t sweat it.
- 1. Be willing to rip out all your old code. Honestly evaluate your systems and decisions
- No one ikes to estimate work. It helps if you have a process. Small stories, well defined features, MVP. The large the feature/story, the worse you are at estimating. You WILL under estimate effort. What you think will take a month, will take 3. Really, with better stories. You don’t estimate. If your stories are small, estimation becomes a non-issue. It gets done when it’s done
- Passion for your job horseshit. I have passion for my family. For life.. You don’t need to be passionate about that billing system api that you are working on to be a good programmer Programming does not have to be your passion. I like programming. I will occasionally do it for fun. But I have a diverse life, with lots of hobbies, friends and family. Don’t let people tell you have to be passionate to be good. Find what enjoyment you can with your job, and if you love programming, GREAT! But it does not have to be your life.
- These are the concepts I use “every” day. Learn them well.
- If you write a function more that 1 page long, I will hunt you down. If your entire controller is more that one page, I will hunt you down TDD, BDD, whatever. Every public method should be tested. Through an integration test or a unit test. Try not to overlap tests, but coverage is your friend Think of the coder that has to come after you. If you put domain logic in the rescue clause that isn’t cleanup, I hate you. Pry/gdb. Set put statements. Find the state of your system. Just staring at your code won’t fix it. Investigate your state
- Learn these CS fundamentals
- Learn these CS fundamentals
- Learn these CS fundamentals
- It’s worse. So give yourself an edge. Network, meetups, friends, opensouce, Font kerning. The fact that your label is 4 pixels higher than your select. SQUASH BUGS! Don’t be surpised at the horrible decisions made by stupid people and even smart people People are promoted just above their competance Totally real. Is an accurate representation of the world Sometimes a job is a job. And you can learn a lot without the pressure of a startup
- Every group has an asshole. Look around your team. If you don’t see the asshole…you’re it. For the guys. It’s hard enough being new. Women and minorities are not promoted/valued. Stop it. Don’t contribute to an environment of evil. Actively stop it.
- Slack invite