What are camput0r skills you learned in the demoscene that were useful elsewhere?
category: general [glöplog]
like at work, or elsewhere
graphics (obvious), compression (sizecoding), computer architecture (oldskool platforms are great intros to this), software architecture (tooling, though admittedly I learned more valuable stuff professionally in this area that I took back into a demoscene context), and a general attitude that complicated things can be broken down and understood and expressed in simple/beautiful forms.
ah, and ofc audio/dsp as well (at least high-level/basics; the more rigorous theory is something I missed from uni that I'm learning now in my late 20's), again from sizecoding.
What ferris said. However, I think to me the social connections were even more important. That's how I got my first job in the industry.
Quote:
oh 100%, same, and all my jobs after that have been the same story; get connected, get a job. Demoscene started that.What ferris said. However, I think to me the social connections were even more important. That's how I got my first job in the industry.
Debugging, how to spot stuff like memory corruption or leaks or graphics bugs, how to link together versatile projects, how to create convenient build systems...
But honestly the soft skills were just as valuable; how to work in teams, how to work online, how to work to a deadline, how to communicate, how to scope, how to salvage something that's running out of time or is broken...
But honestly the soft skills were just as valuable; how to work in teams, how to work online, how to work to a deadline, how to communicate, how to scope, how to salvage something that's running out of time or is broken...
Another important one: How to fail efficiently and early, and how to dare to fail.
On the more camput0r-y skills, also stuff like how to work with plugin based systems, how to work with UI/UX, how to build larger projects, how to look at foreign code that you've never seen and having a rough idea what it does in a relatively short time.
Cooperative prototyping in distributed teams
Benefits of co-located work and socializing
Putting stuff together for a deadline
Iteration
Benefits of co-located work and socializing
Putting stuff together for a deadline
Iteration
The comput0r skills i learned in the demoscene was to leave the comput0r alone and booze mercilessly.
I just got a academic grant for implementing a compiler for 3D-printed microfluidic circuitry. Part of the proposal is that we will use signed distance functions for efficient computational solid geometry... All my knowledge about SDFs comes from demoscene, 4k intros to be exact.
I was worried that my hobby (demoscene) was taking too much time, so spent some months thinking how to make use of that in my professional work. Luckily, the proposal was granted so I can do SDFs during working hours for the next four years :)
I was worried that my hobby (demoscene) was taking too much time, so spent some months thinking how to make use of that in my professional work. Luckily, the proposal was granted so I can do SDFs during working hours for the next four years :)
It's not really a computer skill, but I think that the demoscene solved/removed my imposter syndrome.
I started in the scene as a musician, and learned most of my programming skills by talking about code with demosceners. I vividly remember kusma teaching me c++ templates at some Scene Event. I felt that everybody was a better coder than me. What I didn't know was that demosceners tend to be extremely good programmers.
So my self-image was that of a mediocre programmer at best, but when I started working together with non-demoscene programmers I learned that I had just been comparing myself to the D E I T I E S you people are. I'd often be among the more competent coders of a team. It showed me how fucking broad the spectrum is from incompetent, negative-productivity nits to jecoute jazz musicians. It's a bell curve, the right tail is very long and very flat that's where many democoders are. I'm perfectly happy being closer to the middle, and I'm not sure I would've been OK with that if I hadn't been taught by you delightful gods, you. <3
(nitpick, yeah yeah I know programming skill isn't one-dimensional, but let's pretend that it is mkay)
I started in the scene as a musician, and learned most of my programming skills by talking about code with demosceners. I vividly remember kusma teaching me c++ templates at some Scene Event. I felt that everybody was a better coder than me. What I didn't know was that demosceners tend to be extremely good programmers.
So my self-image was that of a mediocre programmer at best, but when I started working together with non-demoscene programmers I learned that I had just been comparing myself to the D E I T I E S you people are. I'd often be among the more competent coders of a team. It showed me how fucking broad the spectrum is from incompetent, negative-productivity nits to jecoute jazz musicians. It's a bell curve, the right tail is very long and very flat that's where many democoders are. I'm perfectly happy being closer to the middle, and I'm not sure I would've been OK with that if I hadn't been taught by you delightful gods, you. <3
(nitpick, yeah yeah I know programming skill isn't one-dimensional, but let's pretend that it is mkay)
Always document your code, future self coder will like former self coder a lot more that way!
The REAL deadline is at the demoparty.
The best (and only?) widely-transferable skill that can be learned directly from demomaking is in delivering a viable product to a deadline.
I once suddenly found myself in a project at work where the goal was to get code and especially data as small as possible (it was to be transferred over the net and stored on phones, obviously).
It turns out that how to rearrange and encode your data so that it pleases a compressor is a rather narrow skill! (Heck, even knowing that there exists more compressors than zlib was seen as arcane knowledge that I could get credit for. :-) )
Also, from writing a softsynth, I learned that I like DSP, and that made me choose paths in my education.
It turns out that how to rearrange and encode your data so that it pleases a compressor is a rather narrow skill! (Heck, even knowing that there exists more compressors than zlib was seen as arcane knowledge that I could get credit for. :-) )
Also, from writing a softsynth, I learned that I like DSP, and that made me choose paths in my education.
As skrebbel said, democoders are extremely good programmers. I also underestimated my own abilities because I was always comparing myself with the best of the best.
ALL OF them.
everywhere.
everywhere.
Quote:
Quote:oh 100%, same, and all my jobs after that have been the same story; get connected, get a job. Demoscene started that.What ferris said. However, I think to me the social connections were even more important. That's how I got my first job in the industry.
heh same, got multiple jobs through my demoscene connections, including my current one.
Quote:
It turns out that how to rearrange and encode your data so that it pleases a compressor is a rather narrow skill! (Heck, even knowing that there exists more compressors than zlib was seen as arcane knowledge that I could get credit for. :-) )
This more than anything else for me. Lots of other skills that I use in my job are kinda scene adjacent but this is the most "i would not know this if it weren't for the scene" one.
Well, that and I impressed my internship tutor out of his wits when as an easter egg I coded a rotating 3D logo in a fucking chip design package (Cadence) ;)
Not be afraid of a crash dump, start reading the assembly code, and find the mistake in the original C++ source code. More broadly: not be afraid of anything complex or daring (not meaning I always succeed, but at least I try).
Based on my fascination for coding effects and learning about how things are done, I certainly gathered some still useful knowledge, like:
- all the low level stuff like assembly, disassembly, hex data, debugging, etc.
- image and audio data processing, 3D visualization
- CPU microarchitectures
- size and speed optimization, working with limited resources
- data compression
- Pareto principle (how much effort is needed to achieve which gains) ;)
- "data pragmatism" -> You don't know, how to process some tree based data file with millions of nodes quickly using Python? Let me look at it in hex! ^^
The Art of procrastination while pretending to work hard and then somehow finish it in time anyway.
Quote:
The Art of procrastination while pretending to work hard and then somehow finish it in time anyway.
That.
Quote:
Quote:The Art of procrastination while pretending to work hard and then somehow finish it in time anyway.
That.
But without quality that actually would serve you well in a professional environment ;)