So I made the transition from History teacher to Software engineer in earnest last year in August. I had some programming experience before, but totally just for fun, when I worked as a developer for an online text MUD. I was working at a robotics firm and decided web development and software engineering might be more my speed, rather than doing controls work. A friend of mine trained me for a few months in software engineering concepts. It was hardcore, but worth it. In the end, my current boss took a chance on me; after all, I had no direct programming experience. He made me Software Engineer 1 and probably didn't think much of me at the time. Well, I've been at it for almost 6 months now, gotten a raise, and after a lot of scratches and bruises, I wanted to collect my thoughts and go over what I've learned from being in the pit.
For some background, I do a ton of stuff at my job. We are working on project management software to assist the company in doing HR and just about everything the company does. I've basically been handling tracking employee utilization single-handedly, making easy to read charts for the company managers to track their employees. On top of that, we contract out to a real estate company and create programs that they need for their customers to manage their properties. In the future we're going to work on predictive maintenance for car factories using neural networks, which I've been knee deep in for months now. When there is down time I do translation work. This may sound like a lot. That's because it is. It's also given me a bit of perspective on everything. Well, like I promised, my list of lessons learned over the past 6 months.
1. Fast, cheap, good. Pick 2. One of the biggest things I've learned is to stick up for what you can do, but also to be clear about your own limitations. Getting work done right takes time. Rarely if ever does a job seems as simple and clear cut as the customer makes it out to be. There's nothing wrong with saying that a 30 hour job will take 30 hours, and if the customer wants it done faster, they will have to sacrifice something.
2. You're worth something. I am not a braggart and I do not broadcast my abilities. Partially, this is because when I was younger, my abilities made me stick out and tended to alienate me from other people. I speak 7 languages (soon 8), but you wouldn't know it from talking to me. At work, I felt because I had little experience, that I should be grateful to be given assignments and should accept any deadline given to me. It made me a door mat. I was given deadlines I couldn't reach, I was often left to my own devices without assistance, and more work was piled on. I eventually stood up for myself and said that I'm given too much to do in too little time, and my boss responded with a simple nod and a restructuring of responsibilities.
3. Good programming concepts are like gold. We use Visual Basic at work. When I talk with friends who are software developers, they let out a gasp at hearing this. "No one uses VB anymore!" they'd exclaim in shocked panic (well, maybe not). True, I feel my knowledge of VB won't put me in any programmer hall of fame, but VB is just a means to an end. Good programming involves creating a logically consistent and sound set of syllogisms with a clear end goal and no leakage. During my time with my friend training in computer programming, he stressed to me how important fundamentals were. Learn the data structures. Learn the different sorting algorithms. Understand null handling and type checking. Separate functions and never repeat code; reuse it. End users are by definition unpredictable. Be careful about what you think you know.
4. Always learn. I'm a lifelong learner and an avid reader, but even I slack off sometimes. It's better to know more today than you did yesterday. Each day, I try to learn a new concept, or a new command, or a new piece of VB or Python to understand. The reason is not just knowledge acquisition, but also to train your mind to be flexible enough for new situations. I've done a lot of programming and have met different challenges, and part of what helps me to keep going is I'm always finding new solutions to problems.
5. Rome wasn't built in a day. I know, corny. It's true, though. There's so much to learn. And even after you learn it, you need to apply it. I learned design patterns my first month of programming. Did I understand them? Good lord, no. I was patient, and have gone over the material several times as my skill has grown. The other day at work, I successfully used the decorator pattern to make creating reports easier. I chose the pattern not because I set out to use a pattern and to force it to fit to circumstances, but because each report was different and I needed a decorator to handle the dozens of different reports that the customer may need on the fly.
There's of course more, but I need to get some shut eye, and these were the lessons that stuck out most. In the end, the amount I don't know outweighs what I do, and with each day I feel more acutely aware of that ratio. However, I feel this is the job for me. Why? The satisfaction I feel at solving complex problems is indescribable. I love coming up with complex code to hack and slash the data with a chainsaw until it takes the shape I need. I love presenting end users with software that'll make their lives easier. The utilization software I came up with saves one of the girls in HR at least 2-3 hours every week of compiling data, not to mention the graphs and extra tables she'd have to make and the emails she had to send. For the moment, I intend to stay in this for the long run, and see where it'll take me.
No comments:
Post a Comment