Hello, this is Tanaka from the Coding Factory Department.
On September 29th, CSS Nite LP58 "Coder's High 2018" was held at the Osaki Brightcore Hall. What I felt when I participated was the change in the role of coders, who are no longer just developers, and the ideal and reality in the field.
CSS Nite LP58 "Coder's High 2018"
I reported on this event last time . I participated again this year, just like last year.
The session lineup was as follows:
It would take too long to explain the content of each session one by one, and a follow-up article will be released at some point, so we recommend that you check that or other review articles for more details.
For the events, I will list the title and a brief summary of my impressions.
CSS Nite LP58 "Coder's High 2018"
http://cssnite.jp/lp/lp58/
Keynote speech: How to deal with technological trends Yuki Nakamura (Tour)
Due to a train delay, I was not able to listen to the program. Trend information updated daily. It seemed to be explained in an easy-to-understand way, from how to catch up to how to study. I wanted to listen to it.
Bridging the gap between coders and designers: Seeds of business improvement Yusuke Mizukoshi (Reegraphy)
Improving communication with designers is a problem that coders often encounter as soon as they enter the industry, and even afterwards. And it's the same for designers. It was an eye-opener for me about how to divide up work and the scope of what coders can be involved in.
Front-end accessibility learnings from actual projects Makoto Ueki (Infoaxia), Toyoshi Akiyama (Concent)
Accessibility is often considered difficult because it takes a lot of time and effort to address it. However, with the widespread use of the web, it is inevitable. Even if you think you are addressing it, it is a technology that tends to lack accuracy, but the explanation was so easy to understand that I couldn't help but think about how I could incorporate it into my work.
Analysis facts that coders should know 2018
Daisuke Imizu (S Factory)
Although I incorporate analysis tools such as GA in my regular work, I realized that I had never really thought about the details. Also, during the session, I heard a comment about how coders' value will increase, and I felt a change in the new role of coders.
How to improve website display speed Masayuki Abe (Motiya)
Increase your site speed on the front end!
Ayumi Sato (ism/PentaPROgram)
Two consecutive sessions on speed improvement! It shows how hot this field is, and how it is now taken for granted that it should be addressed. The first session was about why it is slow at first, and the next session was about speed improvement know-how that even coders with low skill levels can adopt right away. It is no exaggeration to say that it was a must-see.
CSS animations that are useful in the workplace by Yoshiaki Ito (Maboroshi)
Here we finally got to the session on "visual implementation." Animation, not just CSS, is difficult to negotiate with words alone. If we had our own recipe book, it would make things go more smoothly.
Taking CSS Grid a step further
So Shikano (ICS)
The number of browsers that support the popular CSS Grid is increasing, and the day when it will be used in the field is finally approaching. This time, we were able to see more specific examples of actual projects, and we were able to get a clearer idea of how to use it in the field.
Closing Talk: Survival Strategy for UI Developers Kazuhito Kida (Mitsue-Links)
What is development? It's not a philosophy, but I found myself thinking about it while feeling its long yet short history...
All of the content was something I could use or want to use starting tomorrow, or rather, right away, and I gained know-how that is suited to real-life situations.
And at the same time, I realized something.
Changing roles of coders: ideals and reality in the workplace From coding as design to coding as programming
What I realized more clearly after attending this year's CSS Nite was the "changing role of coders."
The projects themselves are changing from coding that realizes designs in 1px units that can withstand both CompactFlash and cross-browser, to coding that implements almost system-like functions using Ajax and JSON.
Also, with the advent of task runners such as Gulp, the production environment has changed from the time when we relied on compilers such as Koala.
And. Speed improvement, accessibility, consideration for analysis... "What does the code I write handle, and what impact does it have?" Through interacting with various clients, I feel that it is becoming commonplace for coders to design site coding with these things in mind.
The web is a world in constant transition. In this fast-paced world, the CF where I work has also seen many "ideals and realities" emerge.
Ideal vs. Reality 1: Difficulties in responding to changes in how people are involved in projects
For a long time, coding processes have often been carried out in a waterfall fashion.
The director sets the specifications, the designer designs the look and movement, and the coder makes it a reality.
When I first joined the company, unless it was simple mass production, we couldn't start coding until the design was submitted. Because my main job was to realize the design, I didn't know what to do without instructions from the "upstream process."
As mentioned in a recent article , the nature of the projects that CF receives consultations on has already changed from "creating a design that looks good in any browser and implementing some simple functions."
The first problem that arises is the relationship and structure of coders within a project.
For example, if a function such as a nationwide store search function is to be implemented on the front-end side, what kind of technology is required for the implementation, and specifically how much time and manpower (man-hours) will be required? Will the director or designer be required to accurately and precisely grasp this and give instructions to the coder? Also, when the implementation is advanced after the coding phase, it is often found that it would have been possible to achieve a more functional function with less man-hours (at a lower cost) by implementing it on the back-end.
In this way, the truth of the front end is often only known by those who can write it. If you follow a waterfall-style process, you will find out that the design was done properly in the upstream process before the coder gets involved, and both the client and the production side will feel that it would have been better if they had included it from the stage when various decisions were being made.
If that's what you're saying, then surely we should start with the design stage? Yes, that's totally true.
Therein lies the problem of the system. Just as only front-end developers know the true nature of the front-end, the reality is that coders often do not know much about the work of directors and designers. Even if they participate in the upstream process, they will allocate resources without understanding why, which will lower their motivation and prevent them from producing results, which will ultimately lead to a decline in productivity of the entire project.
There are still some changes to the way website production projects are progressing that have yet to be fully implemented. As a coding professional who works on the "programs" that run websites, finding a way to be involved in projects that is not waterfall-based and that avoids the waste of resources will continue to be a major challenge for me.
At CF, the coders themselves are in charge of coding direction and work in a way that makes them responsible for their own source code, but as the specifications and flows of these projects have become more complex, they are now required to have more advanced knowledge and production progress skills in areas other than coding.
Currently, by utilizing the direction skills I have cultivated, I am actively involved in all types of progress systems, not just waterfall, such as agile progress. In addition, by training staff with knowledge of server-side and back-end technologies, as well as direction other than coding, I am able to respond to client inquiries from an upstream stage and promote the creation of a system that allows projects to proceed in a way that is beneficial to both parties.
Ideal vs. Reality 2: Securing man-hours and resources without affecting the schedule
As before, we must design templates while considering operation, improve the visibility of the source code, and proceed with complex system implementation. We also pay attention to improving speed without being told, and take into consideration advertising deployment and analysis. In addition to receiving direct instructions from clients, the coders now have more to consider in terms of programming, so the "man-hours" required for page production tend to swell compared to the client's desired schedule.
At CF, when we consult on a project, specialized staff with on-site experience calculate the man-hours. However, as I wrote earlier, nowadays, detailed specifications cannot be decided at that stage, and they are examined after production actually begins, so the man-hours increase beyond the expected schedule and resources. Since we are also working on the project while producing it ourselves, depending on the difficulty of the project, there may be delays in securing personnel and schedules, and we may have to work overtime day and night in order to meet the deadline.
Coding is a job that requires brainpower. Lack of sleep and reduced physical strength cannot be underestimated. Mental effects have a significant impact on the final product. Even without such things, it is becoming increasingly difficult to balance the time you want to set aside for sufficient research, testing, and quality control with the time you spend on actual production. At the same time, I feel that the quality required is changing. In some cases, the emphasis is on design, and in other cases, speed of delivery is important as long as the minimum content is guaranteed. The "key" varies from project to project.
While understanding the overall project schedule, you need to finalize the specifications with the client and ensure there are enough man-hours for production. The difficulty of coding itself is also increasing, and the skill level required of CF coders is getting higher and higher in both coding and direction.
At CF, we sometimes ask clients to provide us with a detailed schedule for the entire project. Where does our work fit into the project flow? What processes are there before and after? From there, we can work backwards from the detailed man-hours to estimate the expected schedule for the required response period and feedback response, and then carefully examine how to proceed with production. If the schedule for the entire project is not clearly decided, we may give a rough idea of it and then decide on the schedule together with the client.
If we don't handle this well, it could lead to negative outcomes for both parties, so we will proceed carefully and precisely.
To be honest, we may get tired of asking too many questions, but we appreciate your cooperation. Also, we would be extremely grateful if you could consult us about anything you notice.
From "someone who creates the appearance" to "someone who considers both the appearance and the content," what's next?
Coder change and the fight continues
I think the good thing about CSS Nite "Coder's High" is that it's not like many other events where you just think "This is coming soon!", but rather it gives you a quick introduction to all the technologies and know-how that you can use now or in the near future at any given time.
Even if you hear "This is the new thing!", there are many things that you can't use right away or that you don't end up using. It's more realistic and you can feel the actual "trends of the times". It's said to be for beginners, but it's also a very good event for experienced coders.
It's fair to say that the role of a coder has completely changed from "someone who creates the appearance" to "a developer who considers both the appearance and the content."
Although there are some difficult aspects, the range of things I can do is expanding rapidly, and I am now able to be more involved in production as a "developer" than ever before, which is very exciting.
As mentioned in the closing talk of this lecture, "Survival Strategies for UI Developers" (by Kazuhito Kitada, Mitsue-Links), there have been so many changes in just the past five years since I entered the web industry, so it's a world that changes so quickly. How can developers survive in this environment? I want to look at the web world broadly and continue to actively change in the future.
So, what happens next?
I'm really looking forward to next year's CSS Nite.
TANAKA Natsumi