More Pelican, or how I learned to stop worrying and start developing with others.
Pelican 3.0 is almost out the door now. It’s been great working on a “real” project with other developers for what is, in retrospect, the first time ever.
Some programmers I know would rather fork a project and trudge off into the snow with the code base, then fork off their own leg and write their way back before working on someone else’s code; I think at some point I caught that same fever from someone close to me. I think the phrase tossed around was; “The only thing that is worse than someone else’s code is working with someone else’s code.” The crazy part is, after actually working with other people on a project I wish I had done it earlier.
After fitting in to someone else’s product and pitching my ideas and work into it instead of trying to run in it I almost don’t want to go back. Not everything I’ve suggested flew, some things were downright rejected and other things had to be rethought to fit it all… but it was a great experience to have a driven goal and to contribute to it. Luckily the Pelican team is also small, awesome, and very supportive so I’ve found it downright pleasant to work with them… I realize that not every team is as friendly and constructive as the Pelican project has been but the concept of check and balances and the feedback alone is invaluable.
Yes, there is a part of me that wants to be the solo super programmer hacker that gets an idea and sits down to write the next program that becomes the next golden standard but we can’t all be Linus and honestly, who wants to maintain that project into the ground? I’m not an amazing programmer, maybe someday I will be after lots of training. My programs work but without constant learning and challenges they aren’t going to be written well.
While cleaning out little bugs and documenting things over several times may not be everyone’s best use of time; I feel getting used to have to test everything, double think my commits, write tests for everything is important. Normally I can be a little lazy with my commit, get it in and test it after that… but I can’t just do that with a bigger project. On a personal project you can quickly develop and learn bad habits. Working with a team forces good habits, or at least as good habits as the team itself.
For big professional life time programmers I am probably preaching to the choir. Term development, code review, and focused controlled projects with deadlines are vital to putting out great projects. For all those that have been playing the part of the antisocial developer, like I was, I really recommend finding a smaller project that you can help grow, getting in on the channel, and getting your team coding on… you will be shocked how great it can be to work on a project together once ego gets set aside.
The project has sidetracked several other of my side projects, but in one of the best ways possible considering the amount of joy and constructive knowledge and experience I think I am getting from it. I still plan on learning more languages, namely lisp… but right now I am juggling working on this project and studying reversing, one of my biggest interests for the future.
As a whole sidetrack to this whole post, I think that infosec is where I am going to steer my career and reversing and malware is my current big “interest”. Even if I can’t grok it enough to become a professional malware analyzer or software analyzer, learning some of the lowest levels of computing and programming will help me understand all the other facets of security and infrastructure that much better. Not that infrastructure management isn’t a great career, but I don’t feel it’s really focusing me where I want to be long term. I have days where I really regret stepping up from Sr. Systems Admin.