I didn't realise they'd shut! I visited maybe mid-November last year and really enjoyed the atmosphere. They had this bizarre glowing pool for the entrance where you need to hop over some rocks to get in.
363 karma · joined February 14, 2017
> I've seen (and briefly played with) tools for some languages that will create flow diagrams from your source code.
Could you share what those tools were?
Spreadsheets would be much more maintainable if people separated data from the view.
What stood out to me was the instant feedback that's provided when the pipeline was modified; you can immediately see the ramifications of your actions.
I've worked on some projects using Node RED (https://nodered.org/) and have found this to be very true. It's painfully obvious that you're in for a fun ride when the code is literally spaghetti.
I think programmers should be trusted to write code as text, but the IDE should in some way help visualise how data flows through the system.
Intentional programming seems interesting. Reminds me a little of BDD frameworks like Cucumber (https://cucumber.io/docs)
I think there's an opportunity for a big player in the dev tools space to create a mainstream visual programming language and associated tooling. Many are trying, like Luna (https://github.com/luna/luna-studio) and Dark (https://darklang.com/) but I'm worried they're not established enough to gain traction.
Unfortunately programming with a text editor has become so mainstream that investing time in learning potentially better tools nets a lot of friction and not to much gain.
I’m keen to see how Pika Code improves the end to end dev experience by presumably being tightly integrated with deployment. Remind me of Dark in a way.
I'm definitely going to have a close look and migrate most of the components over. Thanks!
> Starting from a place where the details don’t exist inevitably means you will forget or overlook something that will cause your plans to fail or lead to suboptimal results. Starting with the details and repeatedly compressing to arrive at the eventual architecture avoids all the pitfalls of trying to conceive the architecture ahead of time.
While I disagree that OOP is completely useless, I have found that designing a solution with an OOP mindset can lead to a time consuming and tedious exercise of trying to figure out the best names and interaction patterns for things that might not need to exist to begin with. Sometimes a language constraint or the design of a library you want to use prevents the OOP vision from being realised in the implementation.
Sadly I see a lot of this today too. I know someone who has worked on an "agile" project with two half hour long standups a day, two hour sprint planning, hour long retrospective, and various other "ceremonies". I'm not sure how much of the sprint comprised of actual work.
> Sometimes, teams wouldn’t get feedback for months.
Feedback is so crucial. It frustrates me that business process and politics sometimes gets in the way.
> unless you’re starting with a heavy weight process to begin with, you’re not going to see much productivity gain
Agree 100%, The scenarios I've mentioned have always been short term (~4 weeks) client engagements where there should've been absolutely no room for needless process. I worked on a project once where we had weekly sprints (!) with a playback with key stakeholders each Friday. Each week the stakeholders would change, so each week we needed to spend at least a day planning for the presentation.
> It is possible for a mix of waterfall and iterative where early phases (requirements analysis, high level design) are done in a waterfall style while later phases (detailed design, code, test) are done in an iterative manner.
I prefer this approach where time is explicitly dedicated to planning out the solution, which all stakeholders agree to. It also respects that as you begin implementing the solution you'll learn more about the problem domain and adjust accordingly.
While I'm fortunate enough not to experience much of it in the code I read, I do see a lot of websites which grossly violate sane line width rules by stretching the body text to the full width of the browser (looking at you Wikipedia ). Take https://en.wikipedia.org/wiki/Cyclomatic_complexity as an example.
Edit: Martin Fowler's blog (https://martinfowler.com/) is probably a good counterexample to this.
Hardcoded delays are especially prevalent in systems which attempt to emulate a human operator, such as virtual assistants which are starting to replace human live chat agents. The excuse is always UX related. Progressive disclosure is cited a /lot/. Apparently users get a better experience when systems pretend to be human and respond slowly, so we would hardcode delays which were a function of the length of the response message.
My X230 is buttery smooth. The X1 Extreme and T490 I've tried, not so much.
Build quality is solid and keyboard is great. Speakers sound pretty rough but get decently loud. I got maybe 7-8 hours of use with the screen at 60%, and alternating between coding in Emacs and watching some videos.
I've tried Manjaro and the latest Ubuntu 18.04 LTS and have had no issues that would be a deal breaker. The only annoyance is jittery movement with the TrackPoint, but I've had that on every modern ThinkPad running Linux. I've been leaning towards using the trackpad more often and it seems to work okay.
On the other hand, I've had friends who have endured 30 minute standups every day for the past few months. I think they started sitting after the first few sessions.
Code reviews are rare too. Often times you'll be the sole developer working on a particular component of a solution.
I imagined a drag and drop interface (sort of like the Scratch programming language) with English descriptors of the functions being performed. You’d make it a web UI or something that generates a bash script you can paste into the terminal.
On top of that, some airlines like Qantas name their planes (e.g. you'll have an A330 named Cradle Mountain). I'm not sure that the mappings are publicly available but maybe it can be crowdsourced.
I think another major contributor to Fortnite’s success is the scale of cross-platform play that we’ve rarely seen before. Chances are if you have a thing that can connect to the internet, that thing is capable of running Fortnite.
They’re like Facebook not just because they have the money to steal any concept and build it in house, but because in some ways they are a social network. It’s as much as a game as a platform to hang out with your friends and chill.
It's also a great way to learn how complex programs are structured and iterated upon. Games have so many layers of abstractions which are fun to explore :) I'm following the Handmade Hero series which aims to create a production-quality game from scratch - https://handmadehero.org/ - building and engine and all.
I was able to work with someone apt at machine learning while I focused on building out the UI and backend. We delivered a first release about 3 days after we started, giving ample time to seek feedback and let the users shape the direction.