Hello dev.to! I just released my blog.
I'm a first year CS undergrad - and I decided to challenge myself to make a blog. I made a blog post about it, on my blog - or if you prefer to read on dev.to, then read on :)
Two months ago, I went to a French CS competition with a team formed of the brightest in our university. The competition was divided into three eight-hour projects back to back, hence the name 24H IUT Info.
On the second project, we had eight hours to create a bot to play a network game - each bot would then be pitted against the bot of other teams, and the winner would progress. Our organization was shaky and we ended up losing six hours in order to recover for the last project. Nearing the deadline, we decided to implement the simplest functionality to not disqualify: connect to the server, send a random move (a valid string), then wait for a response and send again. 100 lines of Python later, we had something.
We ended up beating more than half the teams on this project : after eight hours, more than half of the teams didn't have a working prototype. Each team that disconnected, had their program crash or couldn't play until the end were disqualified.
Why were half the teams failing in an event that had the best undergrad CS students? I still don't exactly know why, but after making this site I can offer a good guess.
Gaining experience
As soon as uni ended for my first year of CS, I was lacking experience. When faced with making real software, I was at a loss. I read extensively and knew software engineering was very different from the theory we learned, and so I set out to make a simple blog.
There were a few restrictions I made in order to learn:
- I wanted to make it alone, and make it quick: I gave myself a time-frame of about a week.
- I wanted to build my blog from scratch. I used Django and did the rest myself: renting my own server, running my own software.
- I wanted the site to be reasonably fast and easy to read.
- Most of all, I wanted to take no shortcuts: no copy-pasting code from Stack Overflow, and developing a good understanding of the tools I used before diving in.
What I learned
Design your programs, don't write code
Before writing any code, I asked myself: What do I want my blog to have? I spent a long time answering that, changing my answer as the days went on. I think my most important asset was a flexible design that I could change easily and stood on the guarantees I made early on. If I didn't have a design, or I wanted to switch frameworks every time I hit a complex problem, I would have taken a lot more time getting here.
Take the right tradeoffs
There were many times looking for a solution where I saw several "silver bullets" that took more work to deal with later on. I saw many "shiny technologies", especially early on, that I were tempted to use. In the end I avoided both of these and went with the "boring tech" each time: postgres, debian, django. If you continually ask yourself what framework or database to use, it's hard to move beyond that and start programming.
Write as little code as needed
I wrote my site from scratch, but without re-implementing an entire framework, because it's out of my scope. I always looked for well-tested libs that I could rely on without much effort. At the same time, if there were libs that were disappointing, I didn't hesitate to drop them and look for a replacement. When looking for a markdown parser, I cycled through several of them until I found one that fit my design.
Deploy fast, refine slow
Having a wonky product is far better than having no product. But don't forget that it means that you have to go back and fix your mistakes later on.
I spent a lot of time rushing as fast as possible to get a working site - yet I kept track each time whenever I took a shortcut, and went back and fixed nearly all of them. There's still some parts of my code that are embarrassing, which I will fix as issues arrive.
Be thorough
I made sure to learn Django well before I started writing this site. In many cases, when I encountered problems, I had an acceptable solution that didn't compromise anything, thanks to my preparation. When things were off or didn't work, after my initial deployment, I put everything else on hold to make sure that particular issue is fixed, sometimes diving into source code and debugging to make sure I understood the issue and made sure it never cropped up again.
Don't give up
I haven't mentioned the time-frame, but it took a significant toll on my being. I ended up waking up at 5AM everyday, working at least 8 hours, often more. When in this state, you want to hack through everything simply to get it over with. The only reason I didn't do so was my purpose that I defined early on, and without it I would have probably given up and hacked a solution at the first obstacle.
Conclusion
I think that the main issue gating many of the CS students I know is being an eternal student: always learning about new tech and frameworks but never being able to do something with that knowledge until many years down the road. And whenever you do get to do so, it's done poorly, because the student never learnt how to apply what he was taught and think critically.
So that's what I'm trying to get out of. Let me know what you think. If you want to see the code, I've put it on GitHub.
Top comments (1)
Hey, I wanted to comment on your blog but apparently it's not possible, so you end up either missing the conversation all together or otherwise having it as content on someone else's site, you know?
Planning + revision is precisely what makes the difference between "random activity" (no planning required, sure) and actual work (that may also be defined as that something that someone can help you with!)
Anyway, does a graphics exporter from Blender sound as "cool thing" to do in Python? Come over on irc (freenode) in #ossasepia one day for a chat and you might even find plenty of other quite cool things to pick from :)