96 karma · joined May 22, 2018
Considering the popularity of the Android platform and Google's control over it, I don't think it is a bad idea to develop an Android app in Kotlin. According to Google, their Maps, Home, Play, Drive, and Messages apps are all built in Kotlin, and my personal experience is that Android developers like and prefer Kotlin.
TerraStride is an established Portland startup making web and mobile mapping applications for outdoor enthusiasts. We're looking for an Android developer with experience developing and launching at least one high quality app. This Android app developer will work with our team of talented engineers to design, build, and improve our advanced mobile mapping application. A successful candidate should have a strong sense of product ownership and be comfortable working semi-autonomously as an engineer.
Email careers (AT) terrastride (dot) com
I saw several Teslas around the park, and I think it's doable if you only want to visit say 1 or 2 locations, but without a Supercharger in the middle of the park, you will be limited and won't have the flexibility to see everything.
The resort in the middle of the park has 4 J1772 chargers, which would help if you were staying in the park overnight, but we were simply doing day trips.
Either way my intention here was to simply provide an example of a real-world recursive CTE use case.
The one person who did get fired for stealing was simply grabbing laptops, removing them from their box, and casually walking out with them.
TerraStride is an established Portland startup making web and mobile mapping applications for outdoor enthusiasts. We're looking for an Android developer with experience developing and launching at least one high quality app. This Android app developer will work with our team of talented engineers to design, build, and improve our advanced mobile mapping application. A successful candidate should have a strong sense of product ownership and be comfortable working semi-autonomously as an engineer.
Email careers (AT) terrastride (dot) com
I haven't and wouldn't suggest that people be moved to a position with responsibilities over their head If you want to move up and you need to learn more, of course you need to find a way to learn the required concepts. I did this and continue to do it.
My point about bootcamps is most people who finish them aren't out there getting jobs that require knowledge of CPU pipelines. If that IS happening, someone is really bad at hiring.
If you're saying you wouldn't hire a developer who didn't know those concepts in your domain, OK.. I don't know what your domain is. Software is a huge field as I'm sure you know and there are many domains in which the requirements include understanding these CS concepts.
If you're saying you wouldn't hire a developer who didn't understand CPU pipelines in ANY software engineering context, I strongly believe you would be missing out on some highly skilled & capable people.
Most people who go to a bootcamp (I did not, but have hired a developer who did) do not end up working in a role that requires understanding of the 5 topics above you mentioned, with the exception of cache and maybe algorithms. It's just not what most bootcamps are targeted for.
I have seen a lot of terrible code from both sides, and don't believe the quality of the code to be a function of the developer's level of formal education.
Might be different since there could be cameras or some other form of accountability, but I found it interesting.
Since you're probably used to dealing with and migrating your tables manually, I would keep custom SQL for all your complex operations, and use SQLAlchemy for doing basic insert/update/select. Django also has an "unmanaged" mode where you can create a model and it will avoid trying to create a migration to create the table.
Of course, you have to manually update the model if you manually change your DDL.
Watch out for differences on how you are serializing data from Django/SQLAlchemy models vs. raw dicts from PsychoPG.
I like to organize my SQL by keeping each query in a separate .sql file and writing a little wrapper that fetches the files (+1 for caching it) and then executing it. I'm not a fan of lots of inline SQL mixed with Python.
Overall I think it's a great + powerful setup!
Vs. what you can do natively it has severe limitations and the documentation isn't the best (though I think it has improved recently).. but feels native to me.
However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of how apps work in general to navigate your app.
Most people I know, including myself, have found it initially a little more difficult to navigate around apps from the platform other than the one we are used to using daily.
Apps that insist on creating the same UI on both platforms can be a mixed bag, IMO. Sometimes executed well, sometimes poorly. Because of this, I usually prefer apps that separately comply with each platform.
I am however interested in playing around with Flutter soon!
There certainly are poorly written / optimized RN apps. There are also apps that due to their nature/goal shouldn't be RN even at an early stage. (Startup, navigation, threading, network issues for one). However, I would argue that a properly written RN app, within the confines of the problem RN attempts to solve, does not feel heavy and is actually indistinguishable from native.
From my experience I would surmise a lot of badly performing RN apps stem from poorly written JavaScript, especially bad state management (lots of devs who perhaps have only written web JS in the past?).
I think you can quickly outgrow the limits of ORM... at least Django's. Whether it's needlessly fighting with ORM to get joins correct, ORM deciding it's going to loop through n records instead of joining on DB server, simply doing complex aggregates that ORM won't support, or doing DB-specific stuff. Postgres has some amazingly powerful features that many don't know about because they only learn ORM.
My experience: It can end up being double work because you spend an hour getting the query to work with ORM. Then, a week later, the requirements change and you have to add 1 thing for which it's just not feasible to use ORM. Then you're rewriting it completely with hand written SQL.
ORM seems really popular with web/mobile api now, and hand-in-hand a trend of not learning SQL. I think it's too bad as it creates another layer or separation to knowing how your app truly works. It's a layer that is still important to be familiar with, especially as a project grows.
Using custom SQL with Django has been a mixed bag for me. If you dump JSON from your query, some fields won't be consistently formatted with endpoints that still use the ORM. You can "load" the result into a Django model, but it can be difficult to make it work if you have custom fields you're returning from your custom SQL since Django doesn't know how to format them. (maybe there is a solution to this I haven't found?).
I like the approach of using a basic query-builder for routine insert/update and maybe even select.