Earlier quoted context omitted.
> The most senior developer (24yo or so) I see the problem there.
I've seen older developers that call themselves senior, but lack basic knowledge. I've seen younger developers, wise well beyond their years. Age simply isn't a big factor in how you judge a developer.
Things I wished more developers knew about databases
261–270 of 464 posts
Re: Things I wished more developers knew about databases
#262I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data. Part of it may be due to the fact SQL isn't really a programming language b…
Part of the issue is that a complicated database can handle the same SQL query many different ways based on indexes and other configurations. This kind of "magic" isn't always clear when programmers are mostly used to working with data structures and procedural code. The other problem, IMO, is that programming languages are very poor at bridging the difference between the SQL domain and the language domain. We really…
Having the database automatically figure out how to run a query is a great feature, but most of the time I'd happily just write explicit nested loops for the sake of predictability.
Re: Things I wished more developers knew about databases
#263Earlier quoted context omitted.
> The application language was a pass through later between the client and the database. This style of doing things resulted in spaghetti style unmanageable databases, filled with an unknowable number of triggers and procedures, all written in PL/SQL (which is much, much worse than either Java or PHP). The reason why ORMs started to become popular is that you can write your application without filling your DB with ar…
There's a middle way which is very powerful: SQL views (just SQL queries; no triggers or procedures) Here's a powerful mindset trick: think of SQL views as an sort of a REST API , but whose access language is SQL and not HTTP, and that returns data in a table rather than JSON (hierarchical). I once tried to build a REST API to a database, and someone told me I already had a battle-tested and highly performant API tha…
Re: Things I wished more developers knew about databases
#264Re: Things I wished more developers knew about databases
#265Earlier quoted context omitted.
I wish I could slap anyone who gives a hoot about tabs vs spaces. Fortunately modern languages like go are removing the version control problem that not caring about style and using auto-formatting IDEs produces.
The solution isn't to force style on programmers within the language. It's to fix the shitty diff tools that flag whitespace changes as significant.
if(foo) {
or if (foo) {
or if (foo)
{
you end up in pointless arguments. I don't care about this sort of formatting very much (I have my own default style developed over years), but I do care when other people care about it, often to the exclusion of other factors."but we need these tools so that we don't argue about how to format code". Well... you could... just not argue about it in the first place.
Re: Things I wished more developers knew about databases
#266One thing I've noticed that in the medium term of a software service (2-5 years) is that your software should have the ability to do double-writes to and flip reads between two different datastores. That will afford migration with as close to transparent migration with as reduced a downtime or no downtime.
Re: Things I wished more developers knew about databases
#267I never realized this before but many excellent developers struggle with SQL beyond simple SELECT statements. I have a colleague who is by all accounts a deeply technical person but one day he confessed to me that he didn't really grok SQL and that he'd rather work with a "real" procedural programming language to just store and retrieve data. Part of it may be due to the fact SQL isn't really a programming language b…
Re: Things I wished more developers knew about databases
#268An odd thing that happened to me yesterday with the PostgreSQL ODBC driver (psqlODBC) v9.3.400. It wouldn't let me insert a string longer than 255 characters long into a character varying field into a local v9.4 database on windows using a recordset update. I didn't have a problem pasting it in via pgadmin. Altered the field to text and the problem went away. I've a suspicion that there is a limit on text in the tens…
edit: varchar(n) will issue an error past n bytes, varchar without n is the same as text. character varying(n) is like varchar(n).
Re: Things I wished more developers knew about databases
#269Earlier quoted context omitted.
jOOQ can be used in a less-type-safe way. For example, `fetchMaps` [1] does more-or-less what you describe. However, I have found it worthwhile to learn to use the more advanced features you mention. Extending type safety to queries is incredibly useful. Consider cases when developers are making code and schema changes concurrently that overlap. [1] https://www.jooq.org/javadoc/latest/org.jooq/org/jooq/Result...
SQL (at least in Postgres) is already type safe.
For example, if I have a `timestamp with time zone` column in PostgreSQL, that is represented in the generated code. I will be prevented from inserting a Java `String` into that column - I will have to provide an `OffsetDateTime`. (This is how it would be in a typical configuration - it is flexible enough to do pretty much anything).
Another example, let's say I reference some column in a query in one of my feature branches. Meanwhile, somebody has dropped that column on the master branch. When I rebase my feature branch onto master, my build will fail.
Re: Things I wished more developers knew about databases
#270(The 80/20 rule applies below, some developers do care) Developers... just don't care. They want to spin up an ORM, point it at a URI, and forget about it. I've fought this for over a decade now as a DBA, SRE, DevOps, and architect. Most of the developers don't want to deal with anything infrastructure-wise; they want to spend all the time they can just focusing on the problem they're writing software to solve. Obser…
But, what you described is exactly why senior devs/engineers make 2x, 3x, 4x a junior.
Seniors make more because they have that extra knowledge you're talking about that can take a decade or more to accumulate. The idiosyncrasies between different DBMS or even languages or even specific versions of languages. That knowledge doesn't come cheap. It literally takes upon years to develop.
This is partially why I think bootcamps are bullshit. I'm sorry, but there is no way to become a competent full-stack developer, especially if you're not targeting web/browser. Give me someone with 3 months of bootcamp C++, I'd be surprised if they can get a nontrivial program to link, let alone compile.