MagmaRails - Passionate Programmer

Editor's Notes

• #4: Look at 2 months back, 6 months back what do you have to show of?
• #5: programming by coincidence is copy code, make little changes, test make more little changes and make it work without fully understand what's going on, sooner or later, you will have to do things by your own and you will fail.
• #6: It depends, depends on you, on your career plan. You need to have a clear understanding in what you would like to be, senior engineer, manager, owner, etc. why ? Because everything you do will give you experience, don’t waste time learning things you wont use.
• #8: All is business: our companies employ us just because they're going to make money with us, it's not about love, that's the goal, make money. So you need to figure out how to fit in business. but
• #9: Talk with business people, ask them how they do their job and how technology helps them, do this regularly, subscribe to some business blogs, and try to gather a list of questions to ask them, all those questions would help you to understand how business are driven and will make you more unique!Medel Example
• #10: You're following everyone else's plan, you need to follow your own plan!
• #11: In my personal case, that’s why I love to be a consultant, there’s always new challenges to learn how the businesses work
• #13: If you had money, where would you invest in? savings account, low reward and risk, startup? high reward but also high risk. Same happens on programming languages, you may want to learn most common technologies, you know that there's market for it, but you'll get an average salary. Java, Cobol, BeOS, Ruby
• #14: Analyze all technologies, you may want to choose a cutting edge technology, but if it's attractive for someone else, it'd eventually get packed and the reward will go down, but, if you mastered your skills, you can still get high reward. You may want to take high risk learning some technology that is in its sunset, it's highly risky, but if you get a job, you can potentially get what you want, no one else knows it, and all the critical business apps are in your hands, but be flexible, move fast enough before all those systems are replaced.
• #15: Go to job posting sites, and find out which skills are in high demand and low demand, then go and try to get offshore outsourcing companies and what they're offering, get the diff and focus on the ones that are in high demand domestically and little penetration offshore.
• #16: are you waiting to someone else to have mercy of you ? Don't wait to be told, ask! There's a lot of developers around the world that would claim to do the same as you do, sometimes with much lower rates. Become unique! Remember, supply and demand rule.
• #17: Asking is not a sign of weakness, all knowledge that we have nowadays has been inherited from our ancestors, they've been mentoring us, sharing their experiences, find a good mentor, ask him to help you to create a roadmap, based on his experience.Why? they're always using alpha versions, cutting edge technology and they can know how much a wave can last. Who dont know any alpha geek? I bet at least, you know one of them the guy who first installed XP when it came and there was no drivers for modems, the first guy that ripped movies, downloaded the newest game, etc, they're remarkable!
• #18: If you really want to learn something, try teaching it to someone else. Someone else could have a question that you never imagined, so it pushes to the edge.
• #19: you may not be an absolute expert in something, but be sure that your knowledge will help to someone else with less experience, example: go and visit local meetups and offer your help to less experienced users, subscribe to mailing lists, IRC, forums, etc. Eventually your name will appear in search results.MySQL list example, replicationYour fear is the one that is between the pros and know them! When going to conferences, go and pick tables randomly, present yourself, and start meeting people, RailsConf example
• #20: Go to any music academic, listen at the quality, it does not generally sound good, and it's intended to be like that, if so, they're not pushing their limits. When those musicians go and perform profesionally, they're paid to perform, not to practice.
• #21: Managers will have the same budget, it's up to you to part of any group, to be in the one with high rates and faster people, or low rates with a lot of people, imagine the reward on each type of developers, This is incredible easy, and powerful, simple things like installing a small program to resize windows will save you time, shortcuts to open everything needed, startup scripts, shell aliases, commit hooks scripts, when doing a release, it'd be nice to generate automatically the report and send it via email, this would save you tons of time!Startup example, they’re coming with a lot of money and short time
• #25: they're powerful and underutilized, because lack of practice.
• #26: Most of the times, the word methodology is synonym of paperwork, but that's not true. while practicing, you may break the cycle imposed by managers in terms of methodologies, they tend to apply the methodologies that they learnt (sometimes decades ago). what if your employee does not have nay process and you take the ownership, you will rock! PELDA˜NOS
• #28: Blake Mizerany gave a good talk about polyglot, choose the best technology based on needs, not in love.
• #29: Design patterns is the art to document reusable solutions to common software development problems. Go and find open source projects and see how specific pattern was implemented by others. when you have new problems to be solved, you might remember "oh wait, I saw this implementation in this cool open source project"
• #30: Be the worst meaning always playing with people that are better than you, this will push you to the edges! Example, how many of you have played solo Unreal Tournament, Age of Empires, halo, etc! and you feel that you are good at it? then you went to play online just to discover that you're nothing! you can't even respawn.
• #31: Listen carefully, take notes, imagine what your boss is going to ask you after every meeting, email thread, report, etc, what if you discovered a performance issue looking at the response time when finance is running a monthly report? you know that sooner or later, finance team will contact your boss about it, and your boss will ask you have a look, what if the answer of this  is: "Oh yes, I noticed it last week, and I've already placed an improvement" instead of "Mhm, financewhat? ok, I'll set some meetings and see where the problem could be" meaning that you dont have any clue about it.Be careful, being ahead is tricky! remember that you're being paid to do your job, but what if you do job nobody asked you to do, what if you were wrong? move small, 
• #32: If you dont track anything you're doing, you don't have anything to justify your work, you should always be asking yourself: how can I increase the visibility of my work? they might know that you're good, what if they promote you to do the job they dont want to do ? or even worse, work that you hate! make this transparency happen, if they know you well, they will promote to positions that fit you. Look back and see how valuable you have become: if you have tracked all your accomplishments, you can probe the business how valuable you are, and you can get what you deserve, what do I need to do to get as twice as my current salary in 1,2, 5 years?
• #33: good and bad programmers are always going to quit their jobs, and the business will continue no matter what, don't try to probe anything
• #34: Do you remember when you were students, you worked as trainee, earning few pesos, but you were able to go out almost daily, eat, go to the movies, etc ? and right now, it's much harder to do it?? that's because you used to treat your money more valuable and now that you ear more, it's not that valuable, it happens the same when programming, you need to treat your time as it were the most precious thing in the world, you need to sleep well, have fun and code, so, focus in your 8 hours schedule!
• #35: I bet it was when a server was down, when the network failed, hard drive died and you needed to restore a backup from a weird format, etc. you got the work done fast and well done, it’s because the time was high value!
• #36: raise errors as soon as you notice them, dont try to hide, problems need solutions, avoid using git blame! be the ones that find errors, report them quickly and offer a solution.
• #37: we as programmers always feel that saying that we can't do something we fail, but that's the quickest path to loose our commitment and trust ability. Keep sanity, you need to sleep!
• #38: dont speak in cryptic language that they dont understand, you may make them feel stupid with your sarcastic moments, check old emails sent to non technical people and look how technically you wrote
• #39: You're working in a word wide environment, you need to communicate with coworkers/clients across the world, learn how to write well, because you need to improve your communication skills!. Have a look at some job posts, and see how many of them have this requirement (communication skills), or good verbal and writing skills. You are what you can explain!
• #40: Show your brand, create a blog and post what you've been learning, show them the code you're been releasing as open source, they may be using the same technology that you contributed, this demonstrates skills in real projects, you're not saying that you heard about it, tell them your username in forums, your email in some mailing lists. But:
• #41: Google your name, and see what it says about you. Write smart, think in the future
• #42: Dont panic: what does best players share in common? they dont panic, they're always relaxed and know their context, panicking gives us inability to perform at our best at time we really need to perform at our best.
• #43: if you're a manager, ask to your employees if they're bored, if you're an employee, tell them that you're getting bored, whenever they ask what would you like to do next, tell them! I want to become senior engineer, I want to found my own company.
• #44: Focusing on finishing the project leads to forget good processes, and bad processes lead to bad software.
• #45: what are you going to do? everything is in waves, you're either in front, above, or behind. book some regularly time to read blog posts, news, try new technology, do small prototypes and get familiar, your boss someday could come from a conference saying: "look! we're going to change everything to this cutting edge technology!"
• #47: Engineers who love to code derive pleasure from building software in much the same way a composer might feel ecstatic about finishing a symphony. It is that feeling of excitement and accomplishment that makes rockstar engineers love to code
• #48: Smart people know that the best way to solve problems is go straight at them, Instead of spending weeks designing complex, unnecessary infrastructure and libraries, a good engineer should ask: What is the simplest path to solving the problem at hand?
• #49: The original idea behind refactoring was to improve code without changing what it does, this avoids legacy code that no one wants to touch
• #50: Patterns are recurrent scenarios and mechanisms that live across languages and systems. Applying a pattern ensures correctness since it leverages existing know-how: a method for solving a particular engineering problem that has worked before.
• #51: The goal is to create a working system, how can you be certain that your code is actually working if you never test it? Good engineers will always write a test once a bug has been exposed to make sure it does not come back again. But a good engineer also knows not to waste time writing trivial or redundant tests
• #52: Aprovecha! Reinventing the wheel has always been one of the biggest problems in the software industry. Correct leveraging of existing infrastructure allows rockstar engineers to focus on what is most essential - the application itself.
• #53: Good engineers work hard to make the system simple and usable. They think about customers all the time and do not try to invent convoluted stuff that can only be understood and appreciated by geeks.
• #54: The other secret of good engineers is that it takes the same amount of time to write good code as it does to write bad code. A disciplined engineer thinks about the maintainability and evolution of the code from its first line. There is never any reason to write ugly code, a method that spawns multiple pages, or code with cryptic variable names. Rockstars write code which follows naming conventions, code which is compact, simple and not overly clever
• #55: A good engineer might have a favorite programming language but is never religious about it . A good engineer knows that and is willing and able to learn new languages, new libraries and new ways of building systems.
• #56: How can you build large scale software without knowing what a hashtable is? Or the difference between a linked list and an array? And the algorithms are just as important - from binary search to different sorts to graph traversals
• #57: How fun is your work ? when we have more fun, we do better job: bored tasks are not challenging at all, but we need to do them, so ask yourself, why is the boring work boring? what's the difference between the work you love and hate? a simple technique to make it challenging is to pursuit perfectness in those tasks, let's say that you hate unit tests, and you need to automate some test coverage for the most critical flow, what if you pursuit for 100% of coverage? isn't that challenging? you've made a bored task in a challenging one