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
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.
