Been using JuMP as a central part of a big project at work for the past 18 months and it's been great. Very intuitive to use, and lots of helpful responses on GitHub or discourse wherever there's been questions about the best way to do something. Congratulations on the latest milestone!
Really nice to see so many little useability improvements -- like easy temporary envs, syntax highlighting in dependency conflict errors, and more partially-applied functions -- as well as more significant language development on threading, stack allocations, and reducing latency.
If they might enjoy something on computing, I'd recommend
"The Pattern On The Stone: The Simple Ideas That Make Computers Work" by W.Daniel Hillis. It's very clear and well written, is quite short but covers a lot and can be enjoyed cover to cover more like a novel than a textbook.
Automatic differentiation. It's useful to so much computational work, but most people only get a cursory introduction to the topic (a rough intro to the minimum they need to know), whereas really understanding it seems to open up a lot of research.
For being immensely practical, I'm a big fan of
1. "An Elegant Puzzle: Systems of Engineering Management"
2. "High Output Management"
3. "Peopleware: Productive Projects and Teams"
This post seemed aggressive and vague to me. I'm not even sure what problem the author has with these licenses. I _think_ the issue is confusing naming - which seems pretty solvable - and not a fundamental problem with "dual licensing" / "source available" / "commons clause" software?
People can develop software out in the open and say "use it as it is, for free!", "use it as part of a new product, for free!", but also say "please do not sell this software as it is" and "please do not make and sell an almost-identical product using this software". That seems good to me, if the other option is closed-source.
E.g. I could make a product, you can use it for free, I will try to make money selling consulting services around the product (you can compete with me on that!) just don't sell the software.
I am happy to be corrected if there is a problem with these licenses being misused (or misrepresented as free and open source), but the post didn't give any examples.
Beyond the state of the Julia Language (which I am excited to try out since 1.0), the core community comes off really badly in this post, and the previous follow-up discussion on HN [1], and julia-users group [2].
1. It's your meeting and you should write the agenda, not your manager. Usually this is 1-3 things you want to tell/discuss with him/her. It can help to keep note of important things that come up during work for you to discuss at the next 1-to-1.
2. Make sure your manager schedules more than 30 mins, ideally an hour. Prefer longer meetings to more frequent meetings, if that's a trade-off. It's important you can get into long or difficult topics. Often you won't need all the time, in which case you can always end the meeting early.
3. Focus on important topics, e.g. career development, rather than "updates", e.g. week done this week.
4. Avoid cancelling meetings; they're primarily for your productivity/happiness. How regularly you have 1-to-1s should depend on how experienced you are at the job and can change over time - probably somewhere between weekly and monthly. At the end of each meeting, try to arrange/confirm the time for the next one.
The book "High-output management" by Andy Grove has a great section on this, and I've found the advice there very helpful over the last few years.