Advantages of working at home:
1. Equipment I pick.
2. Furniture I pick.
3. Temperature I pick.
4. Lighting I pick.
5. Music I pick (without headphones!).
6. Clothing I pick (shorts in summer, sweatsuit in winter)
7. Food & drink I pick. (It's really good.)
8. Commute time = 1 minute per day.
9. No gas/car expense.
10. Almost no interruptions.
11. 6 people have my IP phone#.
12. 12 people have my cell phone#.
13. Everyone else --> email.
14. I check email when I'm ready, not them.
15. I set my task list (but still deliver as promised).
16. Can easily run errands any time.
17. Can easily do household tasks any time.
18. Much easier to schedule exercise.
19. See SO much more often.
20. 4 legged creatures make much better office mates.
21. People respect my time much more when I do visit the office.
22. Can more easily switch tasks.
23. Much easier to focus all the time.
24. I get twice as much done.
1. basic form
2. form with multi-valued lines
3. form with data set (multi-valued parent/children)
4. form with grid
5. tabbed form
6. form with skins
7. batch (loop thru something)
8. batch update selected records in a table
9. batch dump table records --> .txt or .xml file
10. batch .txt or .xml file --> update table records
11. batch file --> create & populate database table
12. cut an email
13. traverse internal tree function
14. traverse file index(es)
15. build html from parameters
16. build javascript from parameters
17. build .pdf from parameters
18. build hp esc sequences from parameters
19. benchmark a process
20. how does that syntax work?
21. which way is faster?
22. batch string parser
23. batch source code search
24. batch source code changer
I have more, but I don’t have time to find them right now. OK, I think I’ll add:
25. batch parse source code, identify routine for reuse
Maybe we’re lucky in Pittsburgh, but we have the best of both worlds at the main branch of the Carnegie Library. You can take a tour of where I work 2 or 3 days per week:
http://www.clpgh.org/locations/main/tours/virtualtour/
It’s fantastic. It was built by Andrew Carnegie in 1895 and most of it is original. I get inspiration from the 20 foot ceilings and hand made ornamentation everywhere you look. They simply don’t build things like this any more. There are quiet reading rooms, large tables, plenty of light, and oh yeah, a Crazy Mocha coffee shop in the building. I use a cell phone dongle on my laptop and most people know that email is my preferred communication method.
If I need a break, I can look at priceless artifacts in the Carnegie museum through the windows in the open stacks. Or just get the world’s most disgusting hot dog at the “O” a block away. If I need inspiration, that’ll either make me or break me.
One of these days, I’d like to make the claim that some incredible technology of the 21st century was conceived in an edifice borne out of the some of the best technology of the 19th century.
“My aspirations take a higher flight. Mine be it to have contributed to the enlightenment and the joys of the mind, to the things of the spirit, to all that tends to bring into the lives of the toilers of Pittsburgh sweetness and light. I hold this the noblest possible use of wealth.” - Andrew Carnegie at the Dedication of Carnegie Library of Pittsburgh, November 5, 1895.
I believe that there are two ways to get good at anything, “push” and “pull”.
Push: You learn from books, classes, mentors, and studying examples, then apply what you have learned.
Pull: You have a problem that you must solve, then you learn what you need, any way you can, to build the solution.
I suppose there are pros and cons of each method, and I imagine that many people here have used some of both.
For the record, I am 100% Pull. I have absolutely no formal training. It took me 2 years to find my first job and then I was thrown into the deep end. It was simultaneously frustrating and exhilarating. There were so many times I didn’t know what to do or didn’t have enough “tools” in my box. So I had to figure it out and find sources of learning. But I always did. Any when I got that first thing working and then saw my customer’s eyes light up, I was hooked.
Your CS degree may make you think that you’re a “push” learner, but may I suggest that you adopt a “pull” approach. Forget what you think you know and find a job or a project or someone who has a real need. Then build what you need. You a several advantages over me: (a) It shouldn’t take you long to find that job/demand/customer. Just keep looking. (b) You already have tools in your tool box, maybe not the right ones for the job, but you have “something”. And (c) It’s easier than ever to adopt a “pull” approach. Help is everywhere.
You may feel frustrated, but I don’t think you have a problem at all. You’re in a great (and very normal) situation. Just adjust you attitude, find something to build, and do it.
“Work effective hours, not necessarily long hours…”
The best trick I have ever figured out for doing this is to separate all activities into “in front on my computer” and “away from my computer”. If you are working ineffectively in either mode, switch modes. If you are still working ineffectively, consider a break.
I often sit in front of my computer, writing code, refactoring, or testing and realize that I’m getting nowhere. Then I conclude that the reason I’m not making progress is because I’m not quite sure “what” to do.
Determining what to do is an activity that I have found much more effective away from the computer. So I log off, grab pencil and paper and go somewhere else, anywhere else. As soon as I have something I’m sure I want to code, then (and only then) do I return to the computer.
This works both ways. If I’m away from my computer, but feel I’m not creative enough, then I just decide to write something, anything, and go write it. Sometimes just getting the smallest things done opens the doors to getting bigger things done.
I have been in your situation many times and have felt the same way; welcome to the rest of the world.
Face it, those of us who are uncomfortable with the status quo and want more than the masses are outliers.
This is a good thing! Here’s what has worked for me…
Rising out of the ordinary and getting ahead is all about “demand”, not “supply”.
Supply: You can read all the blogs you want, read technical books, and study new languages and so what? You are supplying yourself with things that may or may not make any difference and no one else cares.
Demand: Find out what needs are not being met at your company. You can easily do this all the time without even being noticed, “under the radar” as they say. (You don’t have to go to your boss looking for something.) They are desperate needs not being met everywhere; all you have to do is look. It may be a user, a customer, a way of doing business. Then fill that need. It’s that simple. You will force yourself to learn whatever you have to to get that job done. Then do it again. And again. Before you know it, people will automatically know to come to you when nothing else works.
Business is about getting things done. Learn how to do that whether it’s officially sanctioned or not. You will quickly rise above the masses and your life will never be the same.
A few notes:
1. Most people won’t even realize what you’re doing. For those that do, most will approve. For those that don’t approve, ignore them.
2. With this approach, you will optimize your learning. You will learn what is needed, not what you think is cool.
3. You will become much more valuable for two reasons: you’ll expand your skill set and you will convert yourself from a doer to an achiever. The difference is subtle but huge.
“Despite all this every time I sit down to code my brain turns to mush, somehow, and nothing gets done. I can always give my managers an intelligent explanation of why progress is so slow…”
Oh, so this happens at work…This exact same thing has happened to me many times and here is what I figured out…
The problem is NOT with you, it’s with the work.
Like you I have scored excellently on interviews and tests and have written code so cool I even surprised myself. So we have to believe that we are as good as we think we are. That belief is what enables us to take on the hard projects. That belief is also what turns our brains to mush when our work is too many levels below our capabilities.
Sure, we all do work below our level every once in a while; we have to, that’s the nature of the beast. But when you’re doing low level work for too long (like at many jobs), you lose energy from the lack of stimulation. We then mistake that lack of energy for many other things: our skill, our commitment, even our health.
Here’s what I’ve done in situations like yours: build something cool on your own time. It will get your juices flowing and you’ll be your old self in no time. Of course, you’ll want to work on your own project instead of your employer’s, but that’s another problem.
Wanna know the biggest difference between you and me? I’m pulled. You’re pushed. Let me explain…
I love building stuff. Nothing gives me a bigger rush than getting something working the first time . But I couldn’t care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that’s what I’d use.
What I really care about is how my software is used. And who uses it. There’s an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.
You sound like the opposite. You love the toys and look for places to use them.
My suggestion: Take a break from the technology and put yourself in more situations where people can share their problems. This will give real human meaning to the technology. I bet you’ll be chomping at the bit to build something for someone in no time. For me, being pulled by a demand motivates much better than being pushed by a supply. Maybe it can be for you too.
Some people advocate: 1) private offices for each programmer, 2) free, nicely catered lunch every day (everyone eats together and bonds), 3) usual internet stuff - comfortable office, dogs, flexible schedules etc.
On one hand, a little voice inside of me cries, “Yes! This is what it takes to produce great software: a programmer-appreciative environment.”
On the other hand, another little voice claims, “This stuff is all well and good, but nothing more. It’s cosmetic, not functional, like putting perfume on a pig.”
I have been in many situations with Class A office space, private offices, catered team-building breakfasts and lunches, etc., etc., etc. and was ready to jump out the window. Why? Because the work sucked and all the window dressing in the world wasn’t going to change that.
Then I think back to some of my most favorite projects and remember the great work that we did. Sometimes in squalor-like conditions, sharing cubicles or tables, sitting in the server room with too much air conditioning or in the warehouse without enough, eating vending machine garbage and drinking old coffee because that was all there was.
Bottom line? The “work itself” is 100 times more important than the working conditions. Sure, everything being equal, I’d rather have nicer digs. But everything not being equal, I’ll choose the better project every time, no matter what the environment is like.
BIG disclaimer: I have NO formal training.
1. Tools. I generally shy away from tools. I just don’t like using anything that makes me more productive when I’m programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I want the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming one with my project is. I may not start as fast as others, but that doesn’t matter. It’s not how fast you start, it’s how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it firmware in my brain. It’s not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go very quickly; that code is already in my brain’s RAM and it got there the hard way.
2. Simple Algorithms. Yes! I love this example:
* EnterOrders 08/31/10 edw519
*
return();
I now have a working program! You say you want more features? No problem. Let’s start enhancing it.
3. Debugging. I don’t. I’ve seen 25 different debuggers and I hate them all. Print() is my friend, especially beyond the right fold. Better yet, write code that doesn’t need to be debugged (See #1 & #2 above.) (Of course, this is much harder with “someone else’s” code.)
4. References. Don’t need no stinkin’ manual. I have become extremely adept at about 4% of what’s available to me, but that 4% accomplishes 98% of what I want to do. (OK, I’ll refer to a manual when I need something from the other 96%, but that doesn’t happen too often.) We could talk about all kinds of other things too, like variable naming, how to iterate and branch, and never typing the same line of code twice, but this was a nice starting subset.