Re:Software Engineering ≠ Computer Science (2009)
by pc86 on Monday August 07, 2017 @09:53AM
(#14947415)
> Yes. Or, it's actually rather easy - but it's extremely hard to do well. That's why one shouldn't do it (or, you should, but perhaps for toying with and not for production). See, you obviously know enough about the topic to know this! This is exactly one of those nuggets of "broad knowledge" you need as a software developer.
Everyone should write their own crypto library at least once. Nobody should ever use their own crypto library for anything. :)
Re:Software Engineering ≠ Computer Science (2009)
by custos on Monday August 07, 2017 @10:41AM
(#14947784)
While I was an admin for hackthissite.org I created some basic encryption algorithms for people to break.
One person gave me a step by step guide to how he broke it. It was amazing, and incredibly enlightening how hard encryption truly is.
Mathematical analysis of the encrypted data poor encryption easy to break.
Yes. Or, it's actually rather easy - but it's extremely hard to do well. That's why one shouldn't do it (or, you should, but perhaps for toying with and not for production). See, you obviously know enough about the topic to know this! This is exactly one of those nuggets of "broad knowledge" you need as a software developer. How much do you know about crypto:
- You need to know when to hash ansd when to encrypt.
- You need to know the properties perhaps of symmetric/asymmetric crypto and key exchange
- You must know that you never implement any of these algorithms yourself, you only choose from them.
That's about it. You need to know what you don't know (how to write reliable crypto) in this case.
> If you have a poor understanding of how indexing works, you'll probably have a hard time selecting the right data model.
Right. Basically understanding a database is around the amount you need to implement a toy database. You know the difference between an index lookup and a scan and so on. Lacking that understanding means the database is some oracle (haha) you feed SQL and it spits out data. If you do know a bit more you might have a vague idea about how data sits on pages that are oriented into a btree. You might know that how the disk tree is magically updated in both ends to be consistent even if power is switched off mid-write and so on (I don't know, this really isn't my area - I have coded 13 years without a db). You didn't invent or even deeply understand any of these algorithms to the point where you could write them on a whiteboard. But it does help you if someone asks "what happens to users' bookings if I cut the power?" or "will it be faster to join in the DB or later in the language".
Another pet peeve of mine is people who can't identify NP /exponential problems. It happens several times per year that junior colleagues of mine develop solutions that are exponential in time/space, because that's what the problem is.
Them: "Look, I optimized the order in which we pick the X from the list"
Me: "That will take the remaining life of the universe already with 30 items!"
Them: "Dang :( that took me two days to write"
Me: "Do it the dumb way and get off my lawn"