by Trevor Page on May 29, 2013
Podcast: Play in new window
| Download
If you’ve worked as a developer for a corporation, you’ve likely been exposed to the waterfall model of software development… If not, consider yourself lucky. I’ve worked in this model before and it had its issues, but thankfully I was introduced to the Agile development methodology in the latter years of my career as an employee and I got a lot from the experience. This podcast episode is dedicated to talking about the Agile methodology and recounts my experiences with it and how I went through my days using the Agile process.
In the episode we will talk about:
- Standup meetings
- Backlog grooming
- Story Planning
- Review and Retrospectives
- Story Cards and estimation points
- Sticky Notes for Tasks
- and more!
Plenty to learn about, and plenty to get excited about!
by Trevor Page on May 22, 2013
Podcast: Play in new window
| Download
Alan Robbins is a self-taught programmer who dabbled with programming in college. After not doing to well in the post-secondary system with respect to programming, he changed his major and graduated with a degree in Business Economics and a minor in Psychology and Philosophy.
After graduating, he decided that he had a knack for programming (even if the “system” told him otherwise) so he ended up getting an entry level job as a programmer. Since then, he’s started up a couple of businesses and is now running a very successful software development company with 40 employees and “lives the dream” by working from home.
The Desire to Learn
I’ve said it before, and I’ll continue to say it. Those with the desire to BE a programmer will make it happen. With all of the tools and resources available today, anyone with the desire can learn how to program. It isn’t an easy process and the journey will be paved with failures, but that’s completely normal. In this podcast episode Alan shares the story of the first program(s) he wrote as an entry level programmer. He talked about how the program would “bring the computer system to its knees” because of how poorly coded the program was, but like I said, this is par for the course.
No programmer is going to be perfect out of the gate, and it’s the learning process that is so important. It’s critical to find a mentor and learn as much as you can from someone who has BEEN through the coding trial by fire already. So if you are someone who wants to learn how to code and finds it so interesting, but believe that they are “just not smart enough to be a programmer”… think again.
Links mentioned in this episode
I invite you to reach out to Alan and ask him any questions that you may have about his journey to becoming a successful self-taught programmer. Alan is an extremely nice guy and I’m sure he’d love to talk to you. So send him a message, even if it’s just to say “Hello, I heard you on the podcast!”.
by Trevor Page on May 17, 2013
Podcast: Play in new window
| Download
In this episode of the How to Program with Java podcast, I will be talking about the software development life-cycle. This topic is necessary to know if you will be working in any sort of professional development environment. When I was first introduced to the “methodologies” of the software development life-cycle in my first programming job, I was lost. The goal of this podcast is to educate you on the procedures that are followed by the majority of software development companies.
Lessons to be Learned
Here’s some background on where I went wrong in my first programming job. I was unaware of the different “stages” that any particular code change must go through before it is released LIVE on the internet to the customers. In my mind, as a brand new programmer in the real world, I would just make a coding fix and then push it out for all the customers to enjoy. There were a lot of assumptions that were made here, but the main one was I assumed that my fix was perfect and that I had tested ALL of the scenarios that could have been affected by my coding change. I was also completely oblivious to the “stages” of a code change. For that particular company here’s what it looked like:
- DEV – The first stage where I would make my coding changes and test on my machine
- QA – The code is checked into a central code repository and tested by a QA employee (usually not a coder)
- UAT – Once passed QA, the change would be passed to a real customer who had their own testing environment setup. They would perform tests to ensure that there are no unforeseen consequences
- PROD – After everyone is happy that nothing is broken, the change is sent LIVE on the internet and real customers will benefit from the fixes/enhancements
[click to continue…]
by Trevor Page on May 8, 2013
Podcast: Play in new window
| Download
Keeping on our theme of becoming a success story with programming as a self-taught programmer, I interview a successful self-taught programmer by the name of John Sextro. As a seasoned programmer and agile coach with no degrees or diplomas, John made it to ‘the big show’ by impressing one of the gatekeepers of that coveted ‘entry level programmer’ position. Find out how he managed to kick start his career in today’s interview.
Getting your Foot in the Door
One of the most important lessons that you should learn from people like John (and myself) is that we weren’t just in the right place at the right time… we PUT ourselves in the situations that would lend themselves to opportunities. If you’re having troubles finding an entry level position as a programmer, then maybe you should change the game a bit and look for a job in a company that HAS a software department?
If you’re in a company that has a software development department (even if YOU yourself aren’t IN that department) you are in an excellent position to show off your skills as a VALUABLE employee. If you are known as someone who provides real value to a company, then you show that your true skills (as a programmer) aren’t even being utilized… well… it won’t be long until the company will take advantage of that situation.
It’s much easier to Learn Programming these days
As John mentions, he learned what he knew from books and magazines (which he had to either purchase himself or have his parents purchase for him). These days, getting access to valuable information about programming is as easy as typing something into Google! It’s FREE access to life changing information, all you need to do is show up.
Now some of you pessimists out there may grumble “Well, if everyone has access to the information, then there are probably so many programmers out there that there aren’t any jobs left!”. Well, to you sir/madam, I shake my head. Go do a search for programming jobs on indeed.com… seriously… I’ll wait. [click to continue…]
by Trevor Page on May 1, 2013
Okay so you know how to add some styles and CSS to your webpage, that’s a great start, but what about deciding where all your text should go? What if you wanted to setup your website so that you have some text on the left hand side, and some images along the right?
This is where design and layout comes into play.
The DIV tag
Probably one of the most powerful tools at your disposal for designing your webpage is the div tag. What this allows you to do is essentially outline “blocks” or “areas” for the content on your webpage. You can think if these areas like boundaries for your content.
So for example, like I mentioned, let’s design a webpage that has a bunch of text on the left hand side (perhaps about 3/4 of the page), and we’ll allow for about 1/4 of the right hand side to hold images. Here’s a picture to add some context to what I’m talking about:
Before I jump into the code, I want to talk a little more about the DIV tag.
[click to continue…]
If you’ve worked as a developer for a corporation, you’ve likely been exposed to the waterfall model of software development… If not, consider yourself lucky. I’ve worked in this model before and it had its issues, but thankfully I was introduced to the Agile development methodology in the latter years of my career as an employee and I got a lot from the experience. This podcast episode is dedicated to talking about the Agile methodology and recounts my experiences with it and how I went through my days using the Agile process.
