Working on phoenix-framework more this weekend. Adding some token generation for api’s and channels.
Been working on a JSON-API library for building JSONAPI style API’s in elixir/phoenix/plug/ecto. Trying to avoid using to many macros and focusing on simple bag of functions.
This is interesting. Anyone from google able to speak candidly to the effectiveness of this? Seems like any system this could be easily gamed if your role is not as easily measured.
Working on a json-api adapter for phoenix. Mostly centered around views and a couple helper functions for controllers.
I don’t know much about Rust but it sure feels like its falling into the same trap Scala fell into. Those code examples look like line noise.
I like what he is saying here, but I’d like to actually see the talk. I hope they have a video come up.
Seems that Gary is pointing out that our industry has pointed its self in a certain direction and is charging full steam a head. Building on abstractions we don’t really fully understand, and then building on top of those. I think he’s arguing that while yes we can do so much more with our machines and code, we really haven’t taken the time to revaluate where we are going and if its really working.
I think its a valuable discussion that our young industry needs to have.
isn’t the whole point of abstractions to be able to build on them without having to understand the full implementation?
Yes it is, but how many of those abstractions are bad? It’s like building on a swamp and hoping it doesn’t eventually sink.
His argument is that just because someone abstracted this is away once doesn’t mean we should all stop finding better ways.
[Comment removed by author]
I don’t know what your definition of “youngster” is, but maybe I fit that description – mid 20’s, and have really only been seriously writing code for a few years. I love James' blog, because he seems to have an excellent perspective on development that I find myself agreeing with regularly (and I can’t say that I’ve ever really disagreed with him).
Here’s a couple of points using some of his recent posts as an example:
The Silent Majority of Experts: Before lobsters, I hadn’t really ever contributed or commented on a site like stack overflow or hacker news; most of my sharing was on IRC. As I talked to other people, I realised a lot of people are busy actually doing things and don’t spend time answering questions online (except, in my experience, on IRC) or writing blog posts. There are several people I respect that provided interesting perspectives on a couple of “unhip” languages, particularly Perl. Perl is interesting because it was the first language I really found with a centralised package / library repository (CPAN) and one that seems to be omnipresent on the internet. Almost everyone I know who has been around has written their share of Perl and a lot of systems run that are taken for granted because they are behind the scenes and not really user-facing, but are critical for the proper functioning of the internet.
One Small, Arbitrary Change and It’s a Whole New World really highlights that sometimes a seemingly small change (or design decision) can have a lot of second and third-order effects that will affect the life of the software over time in ways unpredictable when the decision was made. One area I’ve seen this in is when concurrency gets added later; sometimes it becomes extremely difficult to just refactor to get stable code; often times entire sections have to be rewritten to account for this change because the original assumptions didn’t account for later changes.
I’ve not been one to really care much for discussions over this coding philosophy or that one. Keeping in mind Your Coding Philosophies are Irrelevant and The Most Important Decisions are Non-Technical, coupled with my experience with the OpenBSD crowd’s “shut up and hack” philosophy, has taught me to value working code that does its job well over writing it in the latest and greatest language or using $hip_methodology.
It’s late and I’m pretty tired, so hopefully those make sense.
I’m a youngster and I tend to agree with his posts. I think his points are not very controversial for anyone who has programmed for a bit.
If you have never used Postgres you owe it to yourself to give it a shot. It’s really well designed and has a ton of features, as shown by this article. The best thing I transactional ddl, it’s saved me more times then I’d like to admit.
Certifications are what makes something a profession vs a job.
Doctors, Lawyers, and plumbers all have certifications. You can be pretty sure that someone in a profession has a minimum level of competence. They may not be awesome, but they’re not a total idiot.
With software, you have to evaluate each candiate on their individual merits. And figure out what that means. And figure out how to do it. FizzBuzz, is, almost, in a way, a certification. They’re just first-pass filters
The real issue is the possibility of certification mills and/or gaming.
In the .NET world if you saw someone who was recently “C# .NET Certified” you usually took it as a sign that the developer didn’t know how to code. This may have been an isolated culture thing but I think its pretty universal in the software culture that you learn through doing.
I think the closet thing we have to certification right now is a CS or Engineering degree. After that its largely products you’ve shipped, open source contributions, or references from other developers.
I think its pretty universal in the software culture that you learn through doing.
Sure. But then after learning, I can surely prove that I have some demonstrable level of competence.
In theory, this is what certifications should provide, but in practice, certifications generally signal the exact opposite in this field. My guess would be that this is a function of the lack of maturity of software development as a profession, and the pace of growth in demand for developers.
As long as it is easy for a good developer to find employment without spending time and money on certification, only the incompetent and inexperienced seek out certification in an attempt to bolster their spotty résumés.
Right, I find this to be an overall reactionary attitude. But, as computers become more central to everything we do, we must acknowledge our overall responsibilities to the rest of humanity and stop the childishness cowboy coding.
Not all certifications are driven by people bolstering resumes, many times, employers request and pay for certification.
There is a distinction between a certification for a profession and a certification as described in this article.
Doctor/Lawyer/Plumber style certification is usually government mandated because people’s lives and property are at stake. For a large portion of software development there can be shoddy work that gets the job done(most software development) . I don’t think we will be seeing certification on this level for Software for a long time. If we do see it, it will be certification for application domains where lives are in danger (avionics, medical, plumbing). Not in Rails.
The certification described, as well as the certification that pops into my mind, are the tool specific certifications. In order for certifications to be valid and taken seriously they need a certain level of rigor above just learning the tools(Rails) and practices. These are seen as bad because more often then not they are pushed by tech schools and the company trying to pimp their goods. I think these are cultural things that will change with time, but until then we’ve only got the institution, degree and past works.
I will admit to actually being AT said discussion, and therefore, relating more to the discussion itself than to the article’s take on it. That may have something to do with it!
work that gets the job done
Right, I would argue it actually doesn’t get the job done. It’s often overbudget, overschedule, and has terrible UI/UX.
Regardless, I certainly acknowledge that the University of Phoenix-es of the world aren’t doing anyone any good.
The problems you describe I have experienced both in the Enterprise and doing Client work. And I can say with confidence that communication and “specification” are largely to blame. The product owner says X, the developer hears and then makes Y, product owner complains, budget expands, schedule expands. Further the organizations that have these issues are also never given time to refactor systems or code and it devolves into a ball of mud. UI/UX being poor is also largely because the product owner holds the money and power, has a vision for what it should look like and nags until it looks one way.
These are hard issues and its largely why you see so many methodologies, document types, diagrams and protocols in the enterprise and client work.
That said these is not always the case. Your point stands very often. Lots of developers make mistakes out of lack skill and they are paid barely anything for their work!
I think there is a market for all levels of skill in development right now because Bob’s Pizza is going to pay the old guy down the block to whip together a website for him for $50. He learned in a class and can do it in frontpage! If I had to go through the trouble of an expensive certification there is no way I’m making Bob’s Pizza website for $50, there is a good chance I wouldn’t do it for any price.
Agreed! And if software became more of a profession, I think we could help properly guide people into adopting better practices; nobody tells a lawyer how to run a court case, for example.
But, as computers become more central to everything we do, we must acknowledge our overall responsibilities to the rest of humanity and stop the childishness cowboy coding.
I don’t necessarily disagree, but to move in this direction I think it’s necessary to recognize the current state of the world.
It’s all well and good to say that certs should be good, prestigious signals of competency, but you’ll never get them there if you don’t directly engage with the reasons they currently serve as the exact opposite.
Sure. I don’t see certs as a panacea, by any means. But I think that the utter, instant repulsion to them just as disdainful as people who whinge about XML. Certainly, it can suck. Most things can suck. But it’s not always terrible.
I think it’s important though to draw a distinction between competency in a field, versus competency with a specific toolset. The examples you give are all the former, IMO.
A Rails certification would be a very narrow, toolset-based competency, of more value to HR people and those issuing the certs, than to the person taking them.
This is an interesting distinction. I’ll have to give it more thought.
Why do you see the certs as being valuable only to employers? If it gets you more likely to be hired, it’d be just as valuable to the employee. I can see it being valuable to both or neither.
I think there’s more long-term value in learning and being able to apply generic CS/Software Engineering knowledge to a problem, versus knowing how to achieve a very specific task with a certain tool. (I’m probably biased, as I’d like to think that 4 years at university weren’t entirely wasted!)
Yeah, see, my CS degree was basically worthless. I learned much more about CS on my own. That said, I use my tool-specific training way, way more than anything I did in my degree. This may be a function of being a Rubyist.
A tendency towards autodidactism does seem to be a common theme in these sort of discussions. My personal experience has been that my degree gave me the grounding I need to learn any specific tool/concept/whatever that I need to do my job each day. Could I have gotten just as far without it? Maybe.
Obviously everyone’s mileage varies; learning style can have a huge effect on the value one places on a specific mode of instruction, as well as the material itself.
Personally, I think the whole apprenticeship movement has a lot of merit to it, my main criticism of the software engineering element of my degree was that the industry-based project element of it was contrived compared to the reality of working in a consultancy. If you’re going to claim to instruct on “industry-relevant” skills, then you should make sure they actually reflect the reality of the industry…
I think the most important thing is to support genuine learning and useful skill acquisition, rather than the “check a box” mentality that a lot of other certifications seem to entail.
Right! I think that apprenticeship is an excellent model for software education, and we should be doing more of it. In the Ruby world, we have been. It’s pretty awesome.
However, at the discussion, developers expressed repulsion to even ‘I successfully completed this training course’ as a certificate.
https://teamch.at is getting a major overhaul and code cleanup. Pretty excited to be launching this.