Isn't the honest answer "I don't know. No-one knows."?
You also helped me realize that part of all this mess is that I HAVE been feeling old. Well, maybe not old... older. I feel like I got hyper-focused on being a programmer (and I feel I never explicitly committed to it, just sort of went along with it) and now I just realized it's been 16 years.
Something I realized when reading your response is that I winced a tiny bit when you mentioned "finding meaning in your work" - as if that was something I did not believe could be achieved.
I think in my mind it's more about going to work and doing things are not... so made-up. I find this extremely hard to communicate. This may be due to me being too far removed from the actual impact whatever we deliver may have. Or as other posters have pointed out, lack of confidence in the general mission.
Or maybe I haven't yet figured out the real reason and this is just something my brain has made up.
Again, thanks for your response.
Funny thing. A few months ago I've also decided to improve my communication skills - both in reading and writing. (Long way to go...) It did hit me that whatever I end up doing in the long run, communication is the only 100%-reusable skill that can pay off anywhere. And so much time is wasted due to sub-optimal communication.
Forgive me if my central European bias is showing, but I've always discounted how important it is to align yourself with the mission of the company you decide to work for. Seemed to me like it's a complete bonus and luxury if the two overlap, and the default is just... work.
Of course as long as the company isn't actively working against something you would consider your values.
But it's definitely a question that can't be ignored if one wants to do some digging.
If this ends up dead and nothing more than a semi-introspective rant, so be it, served its purpose.I started programming when I was 16. I am now over twice that and still programming. I don't like the realities of day-to-day software engineering. I cannot shake the feeling that I've spent the last 16 years doing it just because of... inertia. The 16-year old me just liked to hack around, learn...
Acting on it, though... :-)
Life seems balanced now, I get to scratch my itches, not unhappy at my current job, and I don't feel like I'm saying "no" and making excuses. A tiny step here, a tiny step there, worst case it turns out to be a pleasant stroll.
One related story I like is how Assetto Corsa Competizione devs bumped into "weird" behavior emerging from their simulations which seemed like a bug - but then confronted with the actual manufacturers and found out that it happens in real life as well:
https://www.youtube.com/watch?v=PFxIZ-9Awj4
Highly recommended, video is titled "A traction control bug that was a realistic feature".
EDIT: And this is before you get to aerodynamics, which is a whole different can of worms. With todays GT3 cars, how you simulate the front splitter and rear diffuser can make or break the accuracy of the simulation. It's fantastic stuff. Wish I worked on this day-to-day. On the other hand I have trouble putting it down and going to bed when doing it as a hobby, so...
I want to get a better sense of marketing, and how it fits in with the process of building and releasing a new product.I _think_ I've always trivialized the marketing aspect of startups & products. It's no rocket science, right? Either ads on social networks* or posting links on places like HN/PH and hoping for the best.Is there more to it? What are some good resources to learn about some...
What's some of the best writing on all aspects of technical debt that you've come across?
Asking mostly from the developer perspective (so the interviewee), but if you were the interviewer and had a memorably positive experience while interviewing someone, don't hold yourself back and tell about it.You don't have to name the company.
Why is there such a strong tendency towards treating things as a this-is-it(-this-time-for-real) thing? This only confuses people and muddles up expectations.
It's a pretty standard Django app. Some bland Docker trickery around generating the actual challenges/problems, but that's probably it. Simplicity was definitely a goal. I wanted to waste the minimal amount of energy on stuff that wasn't directly related to the implementation of the challenges themselves.
I also have this weird idea of keeping the site as JS-free as possible - in homage to... simpler times.
A few words of background - I was always sort of frustrated how unbelievably dull the usual programming challenges are. I mean all those nearly pure CS-y things that make you invert binary trees and stuff.
They don't really translate well to what the real world offers, and having solved quite a few over the years, I've always been left with the thought of "what the hell did I actually learn?".
The answer was, usually, not much. It's all theoretical skills that fade away if not re-enforced, and that's what I found HARD, because at the end of the day, it all seemed like folly, especially compared to what I had to handle at work.
I had a few ideas, so I put it all together and released a set of 5 challenges. Take a peek inside.
I've always had this general idea of building a truly ambitious-but-also-down-to-earth community, so I hope to push it that way over time.
But like the sorry excuse of a landing page says, this is step zero - you have to start somewhere.
Would love some feedback!
- learn the bare minimum: up, down, left, right, deleting words and lines, stuff you do everyday
- DON'T just look for tutorials learn stuff out in the void, you'll waste time since you'll end up forgetting 95% of it. don't distract yourself. Screw four week plans, the basics you can get in an hour.
- work. write code/stuff. whenever you catch yourself pressing a button > 3 times (you know, left-left-left-left or something like that) THEN look for a better solution. you'll discover plenty ways to navigate around the code you're working with. find a new way, stop looking, start using it.
- happy? no pain points? good. keep using vim, wait until you find something you'd like to improve. look for a solution.
The point is... just because vim can do something, doesn't mean you need to know it. It doesn't mean you need to use it. It's a tool, it's optional.
The other point I guess is... stop worrying so much about if you're using something "right". Are you happy with your workflow? Good! That's what we're aiming for.
These plans and intros and guides... it's almost like they're meant to overwhelm. It's a damn text editor, you can use 4 commands and be happy. There are no rewards and no raises for "knowing" 60%+ of vim's feature set. And after the basic what, 20%? it's diminishing returns anyway.
"hero" - I smiled here! :-)
Are the main characters in books, plays and movies called "heroes" in Latvian? I ask because it is so in Polish. In English a book has a protagonist, while in Polish it's the "bohater" ("hero") of the book.
"A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]" so they'd have at least years to fix it were they using md5?
He says they'll migrate, but it's no reason to go crazy. If anything, calmness of this sort is what we need more of (this industry, anyway... we go crazy about stuff way too much).
As for the parsing, it's done on the back-end, front simply fetches an AST every time input changes.