HN user

bartaxyz

86 karma

https://ondrejbarta.com

Posts6
Comments33
View on HN

I guess it's relevant mostly because the general population might use it for that purpose. Having the model do a search instead would be much better.

Wouldn't matter for a tech demo, but once you deploy this on all Android devices, it matters.

The two that I still actively use

- Danish Swimming Water Quality App[1]: Native app for my iPhone that I use to check the water quality. The official one wasn't working for me, too slow and too buggy. Ultimately, it's just a JSON of public data spread on the map, very simple. - Artwork Framer[2]: Script using Blender that converts .png into a framed 3D model. You can even adjust the frame if you want and then export it as a model to be used in VR (works even in Apple Vision)

[1] https://github.com/bartaxyz/denmark-swimming [2] https://github.com/bartaxyz/artwork-framer

I signed up for it, and I'm not expected to code anymore (I only do so in my free time nowadays - which actually made it even more fun!). But my company expects the engineering managers to be basically at the same level as senior/staff engineers when it comes to experience & knowledge. Part of my work is coaching people, which now I cannot really do in many ways.

But I'm on a good end anyways, since I have a team of people that I know I can trust with things. So I'm here mostly to find out what would be the best way for me to approach this. Thanks for all the advice!

Very blunt, I appreciate that. Though, engineering leadership is certainly different than other types of leadership. Managing through example was my current way of working. I'd be collaborating with engineers, and try to coach them when I could, or sponsor them when I couldn't (provide with either internal or external coaching).

I didn't mention that I'm coding in my initial post, and the reality is that I currently don't code at my job. So while I appreciate your answer, it doesn't really apply to my case, or my question.

On the opposite, I find that sharing code across full stack is becoming overrated. The reason I'm saying this is because that often leads to some very messy dependencies, and maintaining that codebase can become really difficult if you're not very careful.

Additionally, I found that in some teams, people would use some backend code on the frontend, resulting in some security vulnerabilities (server-side logic running on FE instead of BE). Instead, now that we have backend (Go) & frontend (TS) teams at my work, both teams consider the best practices for each environment with more focus. You could say that the same people do that with the same stack, but in my experience, if you allow people to put more focus on the one component they're building, they'll just build it better than when they have a plethora of other dependencies to consider.

The main problem could be talent, as if you have specialised people, you always have to hire for both of these positions (or train your people in either direction internally). But I honestly never experienced a shortage of people. It's more of a problem if you have a shortage of money, at which point, you should just use whatever you can build with the quickest to keep your business afloat.

With Swift UI & Jetpack Compose, I found it really easy to make a jump from React to either platform. The mental model is pretty similar to React in both. Sure, Android is still a lot of boilerplate (in my opinion), but Kotlin & Swift are also relatively easy to get into, especially if you happen to have some OOP experience.

There really should be a way to tell browsers up front about these things like changing box model for all elements, so that it's not forced to apply it for each element on the page one by one.

While I'm sure there are many optimisations already in place, at least we could avoid this anti-pattern that everybody's doing on web these days.

That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.

That I see as a likely outcome. Though companies may still offer an option to have a secured wallet (non-custody) for longer term storage of value. There aren't many but there are a couple of options like that out there where you give custody of the funds where you want ease of use or automation (trading, savings plans, etc.) and then have non-custody as part of the same service where you store whatever you don't want to give the custody of.

I pretty much second that this is one of the biggest flaws. I'm often assured by people invested in web3 that this is a problem that's going to be solved soon by the flood of designers entering the space, but my doubt is growing with each passing day. It seems more likely that this flaw in the system is going to persist for many years to come and very sadly, many people are going to lose a lot of money through it.

Yea, for a senior person it's possible to quickly transition into something like this from my experience. Furthermore, there's still loads of web2 type of development that needs to be done around the web3 part. That's where it's useful to know how the space works, but not strictly required for a lot of things.

In the React Native app I'm working on, I actually noticed this gesture on an iOS simulator (I didn't know about it before) and it worked well. React Native uses native components to render the UI, but it uses JS for the logic of what and where should it put the native components. I think this might be an issue in Flutter though.

I develop with React Native in my day job and I'm observing all the UI changes that are happening in the systems. So far there aren't many problems with the differences, for example in the alpha version of Android 12, Google introduced a sparkly ripple effect (they eventually removed it again). But this change was automatically propagated to all our interactive components of our React Native app, no changes to our codebase necessary. And this is the case for many other changes, since React Native uses actual native elements.

And many React Native questions are going to be the same as React questions. Generally if I have a question about some React behaviour, I wouldn't mention React Native since I'd want wider audience for answering my React question.

The beauty of this solution is that you are free to fight in other states for legislation. Instead of it being imposed to the states by the federal government even though the local population might not agree.

There's a use-case for more than a single approach. Margins and also collapsible margins are tremendously useful. In case of text of an article for example, where space changes based on other elements on the page (e. g. larger space above headings - the linked article also uses them).

In addition, if there's also CSS for `:first-child` that removes the leading margin and `:last-child` that removes the trailing, you can easily wrap them inside another component to remove the margins (or introduce a property to collapse them if you prefer). Of course, this is a bit more advanced and needs to be included in the documentation.

Vibration API 5 years ago

In Chrome, there's already a toolbar displaying that you can install the website as PWA. In addition, a lot of websites already try to stop you from using the web in favour of using the app (e. g. Reddit). So, I don't see this as a new annoyance.

I sincerely hope that we'll never know Satoshi Nakamoto true identity. It's been so freeing for the Bitcoin community to not have this sort of real figure, but mostly an idea of one. It doesn't tweet, it doesn't have good and/or bad takes. It doesn't have a face you could like or dislike. To me, and many others, it's neutral.

I don't believe there's such a thing as "no design" design. It makes very little sense to me. There can be design with very simple and efficient flow but each individual interaction can (and probably should) be engineered.

E. g. where exactly to display the text, what should be the copy, how does the text input behave, where is it positioned and how does it all handle potential error, loading or any other state. To define all of these things and more is to design. Simple-looking visuals don't necessarily mean a lack of design.

I and my peers were mostly freelancing within our software engineering field (for the most part websites & some native development). At some occasions I got to work with hardware but that was rather an exception.

At our class we had pre-defined businesses at first to learn how to file the tax returns. But for a long term project we could think of one on our own. The task wasn't to come up with a business plan though so nobody really had a groundbreaking ideas. We could just pick something like a bakery, research initial investment and go from there.

We could also build a tech project in our last year of school to be excused from part of the graduation exam. We just had to pitch it and present it instead of the exam (we also had to provide code and/or tech documentation). Though we didn't need a business plan for that either. But it was obviously better for the grade if the project had at least a basic business plan.

I studied in Czech Republic and we had entire class spanning out over two years for economic and financial literacy at my high school. On the practical level, we were even tasked to fill out tax returns for a fictional company and we learned how to start freelancing & start a company. It was a high school in a rather small town on the south of Czech Republic, nothing special. I don't know how common this is in the rest of the country, but I remember that I and some of my classmates were leaving high school with income from freelancing already. There are very few people I know that didn't have a source of income when they finished high school.