5 ways to think more like an Engineer

1. Read Technical Documentation.
If you write software, read about new languages, or techniques. If you design buildings, learn about new techniques, materials.

2. Read Context Documentation.
Understand your customer, when you see the pain points of customers, you can understand better how to solve the problems they are experiencing.

3. Think Wider.
If you are trying to solve a problem, try to solve it in more than one way. Aim to meet the same end result with each option. Look at how each can work for and against your end goal.

4. Be social, share
Talk to other engineers, particularly others that are always furthering their knowledge, sometimes you'll find that they understood a subject differently than you, which is good, this gives you another view. Also if you share stuff you build, you might find others are interested in helping out, and show you new ways to solve your current problems.

5. Test your assumptions.
Create a hypothesis about everything you do, and then prove your hypothesis is correct. Do this one day a week. Whether its writing code, simulating the tensile strength of a set of materials you're considering using. Find ways to prove that your understanding of the system is right, even if you are 'certain' you're right. See if you can 'break' what you thought was a certainty.

Good luck, do you have any other ideas of How to think more like an engineer? Share them in the comments.

Learning something New for the first time

I work with an individual on my team who does administrative tasks. She's been here 27 years, I've been here about 6, in the last few years, she's asked about my job and what we do (our team). I don't think many people have bothered go into any kind of details to tell her about what we do, since her main job is most definitely not programming. She has commented that she would like to learn more about what we do, and I've tossed the standard "go check out Udacity" or "go checkout Coursera" out there (from a programming perspective). But, that is poor form on my part.

This morning I decided to change that. It only took 5 minutes, and she did her first "hello world" in perl. Her eyes lit up, and she about jumped up and down she thought it was so cool to have written her own program. After the new year we'll have a few more sessions. I hope she has more fun, and the excitement sticks around!

There was an XKCD comic that really hits the nail on the head.

I think I'd rather be excited showing someone something for the first time than to "write them off" (if you're reading this, I didn't write you off).  I guess it hadn't occurred to me to just sit down and write hello world with you, it was easier just to say go read this book, or listen to this lecture, then to say "Lets do this right now", I'd like to change that in the future.

If I know something you want to learn, ask me to sit down and show you, right now. I will, if I can't we'll schedule a time. This is important to me and you.

My thoughts on Projects and Learning

While I was mentoring one of my good buddies, we talked about projects and the like a lot. It was interesting, and I came to the conclusion that there are 2 primary types of learning when you're out there on your own. There is learning for the sake of learning, and learning to accomplish a goal (which is not learning in this case). I'll talk about each a little and what I think about them.

School Learning
Learning for the sake of learning is going through an entire API just to read up on it. Learning all the details of a language just to know it. One of the benefits of doing this is that you end up having a deeper toolbox to give you more understanding of the underlying structure.  In some cases this learning may actually give you ideas because you didn't even know that particular aspect of an API or language worked that way or existed. Often times it simply allows you to recognize patterns of problems as well, if memorization is involved. The downside is that it's slow, if you spend the time to read every little bit of an API, or language, by the time you are ready to use the language (or API) they may be out dated.

Real Life Learnin
When you start a job in the real world, you don't just take the tools you learned in school and use them and nothing else. You start picking up new things constantly, and usually (unless you work at a really cush job) you won't be given the time to spend reading every bit. What you find is that you define your problem, break it into pieces, determine what pieces you know and which you don't. From there you research enough about each piece to complete it. The benefits of this approach is the quick feedback loop. You discover quickly what works what doesn't, what's easy what isn't. You also can start hitting a wider variety of items in your toolbox. You don't get the depth of school learning, but unless you are writing a very complex piece of software, or debugging, a cursory understanding is sufficient to complete the task usually.

When you set out to learn what approach do you find most useful? Do you use one or the other? Maybe a hybrid approach?

Why I decided to become an Engineer, or Why do I do what I do

When I was going to school, I would ask other students occasionally why they chose Engineering. Often times the answer was "My father or mother is an engineer, so that's why I decided to be an engineer". Occasionally, I would get a "I liked to take things apart so I figured ...>Engineer". Rarely I would get a "I don't know, someone said I should be".

While there is no right or wrong answer, doing it just because someone told you to just doesn't seem quite right. Doing it because you look up to someone is a pretty cool way to get into it, although without that curious nature I think you're pretty limited. I'm sure there are tons of awesome engineers who are engineers just because someone they looked up to is an engineer. And I'm sure people look up to them even now (which is pretty cool). If I were to pick a reason someone should become an Engineer I would have to go with the second choice personally. If you have a curious nature and like to look at how things work, thats headed in the right direction for what I think makes a Rockstar Engineer.

But this post is about why I decided to become an engineer, so I'll tell you (by the way, if you are an engineer, or well anything, tell me about what made you decide that career choice!). Way back when, I moved to Albuquerque to work on Flight Simulators for Lockheed Martin, it was a pretty cool job, but I was hired as a Tech, and thus was supposed to do "tech" stuff. This meant only hardware, even if I looked at the software and found a problem I wasn't allowed to fix it. A "degreed" engineer was supposed to fix it. I really loved how you could control something physical with software (re: I/O and robots, and lots of embedded stuff). I decided going back to school was the only way I would get to play with that stuff professionally. Back I went.

A number of years later (working full time and occasional semesters of full time) I managed to get my Computer Engineering degree from UNM. Just having that piece of paper opens a lot more doors I think. However, if you don't have a curious nature and want to learn more and more. You'll start running into more and more doors closing as time goes on. Just having a piece of paper might get you to an open door and talking to someone (especially in the early days of your degree), but if you're not constantly bettering yourself, and pushing yourself to learn more, you'll find you're falling behind.

Why do you do what you do?

School, Learning, And What to do with it.

People complain about having to take classes they don't think they'll ever use. And I fell into that camp for a long time, in fact until about 2 days ago I fell into that camp. What changed?

I became a little more enlightened. You see, I don't need to use almost anything I learned in school, except for some of the solid basics, you know, reading, writing, arithmetic. Its when you start trying to solve harder problems that people don't ask you to solve, that you discover that using those tools makes things easier.

I'll give you an example.

I was working on testing some code, it's pretty complicated, and it requires lots of inputs, it outputs 3 values. Now to figure out how to get a particular output can get kinda tricky. So analyzing the function, if you can reduce the number of inputs that change the particular output that will make your job easier.

One way of solving this problem is attempting to plot the inputs, and the outputs and look for commonalities. This was my first attempt at solving this problem. After speaking with a fellow colleague (You know who you are, if you want to be credited I'd be happy to link to you), he suggested that I could write a search algorithm. You see, I had completely forgotten about finding "maximum" and "minimum" values, I even think I heard about it in my Machine Learning class, but unless you are actively searching out these problems it's easy to forget that there are solutions you've already learned about.

Even better my colleague suggested that that particular line of code might be to prevent the variable from causing out of bounds (WITHOUT EVEN LOOKING AT THE CODE, THAT'S HOW GOOD HE IS). How did he know this? He listened to the signals. I mentioned things like Cosine and Sine were being used in the function. He knew at a high level what KIND of calculations were going on. So he made the guess that it could be protecting. He was right!

So all I can tell you is to keep actively seeking out those problems and using those tools we were taught. I was wrong. I can admit it.

Designing Learning

In today's day and age, is the current methodology of teaching the best approach?

Here's my hypothesis, Changing HOW we are taught can net greater results on a broader spectrum of students.

It's a well known fact that there are different types of learning

from: LD Pride

These Learning styles are, Auditory, Tactile, and Visual.

How can we improve each of these area's in today's classroom?

I believe that if a student doesn't "care" about what they're learning, it's like trying to force oil to mix with water, it doesn't work.

What we need is something that will be the go-between from the oil (the student) and the water (the material). One way to do this is by not stifling creativity, and in fact fostering it, the best engineers in my opinion are the ones who find the most creative solutions!

Point in case, I'm working on my microprocessors class. Right now we are learning how to handle interrupts, using timer's, buttons, led's and various other things. Individually these projects are dry and don't inspire creativity.

My solution suggests that the student attempts to create a game in one case. For example, Simon Say's, a great game, could be a pretty easy one to build, but in building that you learn a lot of things, here are many of them I can think of:

1. LED Outputs
2. Pointers
3. Timer's
4. Interrupts
5. Button Presses
6. LCD (maybe give the user a score?)
7. Stack
8. Algorithms

So I could manage to learn all those things and actually have fun doing it.

I am so far having a blast with the class because I can SEE the potential I'm given while learning this information, but many people see it using blinders, where they can only see what's directly ahead of them, and not see the potential, I believe that letting student's pick projects force them to learn how to design a project, work through the team building details, and the final implementation. I don't think this should be a one time project that is part of graduating, but shoot find a project that the student needs to complete that takes each piece, and as you learn, you can build more and more.

For example, let's say you're given a project as a freshman, some of the techniques to build this project may require math level x (doesn't have to be overly difficult), as you push through each semester you can learn more and then literally apply it to a project as you go along, so when you finish your degree you can say...Look I completed this project and it required knowledge and skills in all these area's.

How do you think learning should be implemented in today's day and age? And do you have any ideas for programming that may induce learning indirectly?

Design and Programming..a Love affair

Let's take a look at design.

If you design your project well, looking at all possibilities up front without coding a single thing you can catch some problems up front that you may run into. One of those may cause messy or unneeded code! That's again the beauty of the artist they can choose whether they want to keep repainting the exact same thing or really go out there and paint something new!

What all can be designed?
For Microprocessors where you have a limited number of register's to use, defining a personal/project standard allows greater code re-use, as well as less code and easier to understand code.

If you define a register as the UART pointer from the beginning and make sure not to change it, you won't have to constantly be re-writing the code to setup a pointer. How many times does that have to happen? Well if everytime you have to drop into your interrupt service routine and determine whether it was a RX or TX bit that sent you running, that's 2 times for every "interrupt". I know it doesn't sound like alot of time, but when you run into a situation where your time is critical, 2 instructions can make that difference.

The short time that it takes to design your project, can multiply the rewards exponentially.

Deciding how you want to setup each module is part of design, would you rather setup the entire initialization in your main routine for each module, and let that handle everything OR modularize everything and put ALL uart related items in the UART section.

This brings up the good point of .include files, by putting all your setup into a .include file, you can now start using that file in new projects and rather then constantly having to re-write a subroutine you just write it once, and any improvements you make are better for all programs, (provided they are in fact better). Writing this I already see a flaw in the design of the program we made in our latest lab!

Guess what? Looking back on it, I realize we have a file called variables that contains the ".set" items that point to the UART and all other associated names, this means that every file that I try to .include the UART routine into has to have the entire variables file included, Guess what we did that with a "register setup file too!!!".

How can this be improved?

I can put all registers that the UART EXPECTS to use in it's .include file as part of the initialization, and make sure that any time I use that file those particular register's are in that state before the subroutine is used, this can occur by pushing the register settings to the stack before any updates to them, then reverting them back, will allow the subroutine to keep using them as expected.

If there is one thing I'll stress, Try to make your code as uncomplicated and easy to understand for yourself and others, Implementing a design can aide in that.

Let me know how you design!!

How to Microprocessor

Recently we were given a lab in microprocessors that requires us to handle alot of interrupts somewhat simultaneously.

For someone that walks into this lab unprepared it can look like a lot, but for some that's a challenge and for other's that's an active barrier, rather then choosing to be prepared for it, you just walk through and hope for the best.

Reading manuals on the syntax or basic tools to use while programming the microprocessor can be boring, and often time's it's easy to forget about what you just learned.

How do you approach a problem like our latest lab (or any other programming project for that matter)

1. Design --You need to know the "picture" you want to paint with your code.
2. Concepts -- You need to know "how" painting that picture can be accomplished
3. Syntax -- You need to know how to "paint" that picture.
4. Testing -- You need to know how to tell if the picture "looks" like you want it to?

I think those are the 4 most important concepts of programming that really need to be understood.

I'm going to post a series of posts about these particular topics!!

Digging into New Code

One of the biggest challenges in learning a new system is trying to get a picture of that new system as a whole.

Right now I'm trying to learn a pretty complex system, one of the big challenges is that there are so many SLOC that simply opening a file and poking around won't do you any good.

So the question becomes this:

How does one become knowledgeable on a particular system and how do they find that starting point?

I think this question applies to projects big and small. If you don't know where to start, you will continually find yourself asking the more experienced programmers where to begin.You might even be able to modify small portions of code to do what you want and that works as long as those developers are there to point you in the direction, but when the time comes (and it will) that they aren't there, you have to be able to figure it out yourself.

So back to our question, HOW do you do that.

Of course the simple answer is start at the beginning and READ the code as it progresses, and that is an acceptable answer in a lot of situations.

In other situations it's not so easy, some systems are real time embedded systems, so you'll then have to figure out when you enter your frame again, do you start at the beginning, where you left off, or in a predetermined location?

Here's some questions to ask yourself when you are just starting to look at an entire system:

1. Where do you start and can your program be interrupted,
• If your program can be interrupted, how is it handled, like I mention above where does it start again when it's given control again.


2. What is your program trying to accomplish in this section of code that you're reading
• How does it pertain to the project as a whole.


3. Can you break the code into groups, I.E.
• If your project is a car, can you break it into sections such as brakes, engine, steering?


4. Create a list of all pieces (if possible) that make up each group.
• Look at how they each contribute to the whole.


5. Does each group interact with another group directly or is there a common group that handles all requests to each group?
   
   • Make a web chart that connects each group and primary methods of communication between each of them.
     

Let me know if you have any suggestions as to how to learn and understand large projects that you didn't code yourself.